By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,432 Members | 790 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,432 IT Pros & Developers. It's quick & easy.

HADR - recovery

P: n/a
I have two questions about HADR recovery. I am running db2 v8 fp12.

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)

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? 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. 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.
Can anyone briefly (but indepthly) discribe how you typically verify db
integrity and recovery actions.

Thanks!

Dec 4 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
"shorti" <lb******@juno.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.com...
>I have two questions about HADR recovery. I am running db2 v8 fp12.

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)
1. It is always preferable to do a regular takeover (without force) if that
will work. However, if the primary server goes down and the two servers are
in "disconnected" state, then you must do a takeover by force for it take
affect.
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? 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. 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.
Can anyone briefly (but indepthly) discribe how you typically verify db
integrity and recovery actions.

Thanks!
2. I am not sure about this one, so someone else can answer.
Dec 5 '06 #2

P: n/a
will work. However, if the primary server goes down and the two servers are
in "disconnected" state, then you must do a takeover by force for it take
affect.
You said "MUST do a takeover by force". Does this mean you cannot stop
hadr on the
Standby and have it run as a standard? Or does this mean you would
never want to
stop hadr and have it run as a standard?

This is actually a third question but related to this one...If it is
the Standby that crashed
it is my understanding that the Primary would receive an sql error when
it times out
trying to communicate with the Standby that is no longer there. When
this occurs do
you want to issue a PRIMARY BY FORCE or do you stop HADR and let this
side run
as a STANDARD?

The reason these scenarios are not clear is because I was reviewing the
recommended
procedure to do a rolling upgrade and it shows the Primary being
changed from ACTIVE
PRIMARY to ACTIVE STANDARD, then the ACTIVE STANDBY changed to INACTIVE
STANDBY then finally INACTIVE STANDARD. I was curious if it is common
to move
to a non-HADR mode.

Dec 5 '06 #3

P: n/a
"shorti" <lb******@juno.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
You said "MUST do a takeover by force". Does this mean you cannot stop
hadr on the
Standby and have it run as a standard? Or does this mean you would
never want to
stop hadr and have it run as a standard?
To be honest, I am not sure because I can't imagine why you want to do that.
Just issue the takeover by force.

If you stop hadr on standby (without a takeover to primary), the standby
database (even if hadr is stopped) might still be in rollforward pending
state (but not 100% sure about this).
>
This is actually a third question but related to this one...If it is
the Standby that crashed
it is my understanding that the Primary would receive an sql error when
it times out
trying to communicate with the Standby that is no longer there. When
this occurs do
you want to issue a PRIMARY BY FORCE or do you stop HADR and let this
side run
as a STANDARD?
If the standby crashes, the servers are in disconnected state, and the
primary is still hadr primary (you don't need to do anything). Applications
do not get any SQL errors, and you just keep on going.
>
The reason these scenarios are not clear is because I was reviewing the
recommended
procedure to do a rolling upgrade and it shows the Primary being
changed from ACTIVE
PRIMARY to ACTIVE STANDARD, then the ACTIVE STANDBY changed to INACTIVE
STANDBY then finally INACTIVE STANDARD. I was curious if it is common
to move
to a non-HADR mode.
I have not tried the approach recommended above. Occasionally, I have done
"db2stop force" on the standby, then made changes to standby, then db2start,
then activate database, and then let it catch up with primary (assuming that
the catch up info is still available in the logs on the primary).

At any rate, the procedures for a rolling upgrade are not the same as for a
crash. If the standby crashes, you don't need to do anything until you try
and bring the standby back on-line in peer state.
Dec 5 '06 #4

P: n/a
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 "rollforward" activity of the standby. If
you issue the stop hadr first, you'll anyway need to issue a
rollforward..and 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

Dec 14 '06 #5

P: n/a
The reason these scenarios are not clear is because I was reviewing the
recommended
procedure to do a rolling upgrade and it shows the Primary being
changed from ACTIVE
PRIMARY to ACTIVE STANDARD, then the ACTIVE STANDBY changed to INACTIVE
STANDBY then finally INACTIVE STANDARD. I was curious if it is common
to move
to a non-HADR mode.
We generally only recommend using STOP HADR when one no longer wants
the current incarnation of HADR. I don't believe our rolling upgrade
procedure recommends that and I'm curious what you're looking at.
Here's an example pointer to rolling upgrade in our docs:

http://publib.boulder.ibm.com/infoce...c/t0011766.htm

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

Dec 14 '06 #6

P: n/a
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.
Uh, to clarify, my "yes" is an affirmation of the discussion implying
that the old primary could be reintegrated as new standby by issuing
"start hadr .. as standby" and would automatically resynchronize. That
is, under the described conditions, a restore would *not* be required.

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

Dec 14 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.