why should i restore new stand by if primary crashed?

Harishkumar .Pathangay

why should i restore new stand by if primary crashed?

hi,
i have hadr setup up and running all fine. i have peer window configured. so even if primary crashed i can do take over with out transactional loss.
suddenly my primary crashed [db2_kill command]. then the network also failed. I did a take over in stand by. All fine. so stand by is new primary. After this, the network got fixed. so I start db2 in old primary. i have to re-integrate this into hadr pair as stand by. i issue stop hadr command and then start hadr command as stand by. it is not re-integrating.[coz db in not rollforward pending state] i have to restore the database in old primary. then start hadr as stand by. then it works fine. i am looking for a way to avoid that restore because i did take over in peer window. my argument is peer window should help me in re-integrating old primary with out restore as stand by. how do i do that? db2rfpen is also not helping.

thanks, harish pathangay

Harishkumar .Pathangay

RE: why should i restore new stand by if primary crashed?
(in response to Harishkumar .Pathangay)

Any Helpful Inputs?

Thanks, Harish Pathangay

Mark Barinstein

RE: why should i restore new stand by if primary crashed?
(in response to Harishkumar .Pathangay)

Hi,

You should run 'start hadr ... as standby' only on the old primary (no 'stop hadr' before this).

If it's "not reintegrating", then provide exact error and message text you get from the command above. db2diag.log entries from both sides should reveal the root cause of the problem in case if the command above returned success, but the HADR state is still 'disconnected'.

Harishkumar .Pathangay

RE: why should i restore new stand by if primary crashed?
(in response to Mark Barinstein)

Hi Mark,

Thanks for your inputs. Yes it worked when I issue only start hadr as standby for re-integration of old primary as standby.

thanks, harish pathangay

Harishkumar .Pathangay

RE: why should i restore new stand by if primary crashed?
(in response to Harishkumar .Pathangay)

Hi Mark,

There is also second part of the question. I was trying to use db2rfpen utility to put the database in roll forward pending state, so that I can re-integrate old primary as new standby. this is not possible once I activate or stop/start hadr on old primary.

Let me explain a little bit more. Suppose the primary crashed and I did take over on stand by with in peer window, then there should not be any transactional losses. even if I perform crash recovery or stop hadr on old primary I should still be able to re-integrate as new stand by. even if accidentally we stop hadr on primary, it becomes normal database. it will note be in roll forward pending state. I thought I can use db2rfpen utility to put the database in rf pending state and restart hadr as stand by there by avoiding a restore on old primary.

I understand that it is not currently working that way. But can crash recovery or stop/start hadr be aware of the crash and integrate as new stand by.

Hope I am clearly expressing in words. I kindly request you to trust me I try really hard to explain what I mean.

thanks,

harish pathangay    

thanks,

harish pathangay

Mark Barinstein

RE: why should i restore new stand by if primary crashed?
(in response to Harishkumar .Pathangay)

Hi Harish,

It’s clearly stated in the documentation not to use ‘stop hadr’ if you still want to have your database as hadr primary or standby.

https://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.ha.doc/doc/t0011726.html

I don’t know exact reasons for that. I don’t remember exactly, but this command may simply reset the hadr related database parameters. So, you may need to set them back accordingly before the ‘start hadr’ command. Moreover, there is a chance, that the database may be activated by some application / connection before the db2rfpen call. 

Once again, exact command, error code and message text needed to understand why “it is not currently working that way”.

Harishkumar .Pathangay

RE: why should i restore new stand by if primary crashed?
(in response to Mark Barinstein)

Hi Mark,

It is working when you start hadr as stand by after old primary crash.

suppose if I activate old primary or stop/start hadr as stand by in old primary, it is not re-integrating with HADR pair.

I was expecting that it should re-integrate because there is no additional transactions that were run on old primary. HADR was in PEER state when primary crashed and if peer window is configured there should be no transactional losses. so I should get some advantage in terms of re-integrating with out doing a restore in spite of activation or stop hadr on old primary.

old primary was in peer state when crash occurred, and take over on hadr is happening with in peer window. so from a transactional stand point I am lagging behind new primary[old stand by]. so reintegration should be possible with out much hiccups as far as I do not connect to old primary and run some transactions against it.

I am not very sure if my expectation is unrealistic.  

thanks,

harish pathangay