1) If the primary suddenly crashes would you always want to switch the
standby to the primary by force...or would there be times when you
would want to make it a standard? (and why)
Well...what is the goal you're trying to achieve?
Expected response in an HADR environment is to failover (take over by
force on standby). Another possibly sensible response under some
circumstances would be to simply repair/restart the primary in-place,
i.e., normal recovery w/o performing failover.
Presumably the "it" to which you refer is the existing standby, and I'm
not able to quickly imagine a case where one would prefer to convert
the standby to standard (i.e., issue stop hadr) in response to failure
of the primary. A cleaner approach if you have some reason to seek
that end would be to issue takeover by force followed by stop hadr. As
long as the original primary hasn't rejoined the pair in the meanwhile,
this would have the same logical result but the takeover provides a
cleaner way to finish the "rollforwar d" activity of the standby. If
you issue the stop hadr first, you'll anyway need to issue a
rollforward..an d stop command to bring the ex-standby out of
rollforward mode.
2) Let us say the primary suddenly crashes (someone pulled the power
cable) and you switch the standby to primary by force. Then you bring
the primary back up and issue a START as STANDBY. If you are in
near-sync mode, wouldnt there be a good chance the two databases could
be out of sync?
No, shouldn't be. If the primary was in Peer state and operating under
NEARSYNC mode when it failed, then the only way there could be loss of
consistency would be if the standby suffered a concurrent failure and
lost some log data that was in the standby's memory but not yet written
to the standby's log file on disk.
For instance, the old primary sent logs data to the
standby and crashed prior to the COMMIT. That transaction would be on
the Standby as completed but not on the old primary.
Nope. If the commit didn't make it to the standby, then the standby
would roll back the transaction on takeover.
So the question
is...does this old primary need to have a db restore done? I noticed
an old discussion on HADR that seemed to imply you could just bring
this old primary up as standby now and it will automagically recover.
Yes, with the caveats described above -- primary crashed in peer state,
standby didn't also fail concurrently. Btw, the latter is a NEARSYNC
requirement; in SYNC mode, the standby can also have failed.
Regards,
- Steve P.
--
Steve Pearson, IBM DB2 for Linux, UNIX, and Windows, IBM Software Group
DB2 "Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA
