Re: Two Questions on Restarting HDR (critical data undamaged)

Thank you, Mr. Ozarkar. Does the ability to "reverse sync" (replication updates from secondary back to primary) depend at all on whether the secondary was changed (during the period of primary outage) to Standard or Primary? (I'm now trying to understand the significance of Mr. Pruet's suggestion that it would be advisable to change secondary to temporary primary, rather than temporary standard.) Also, if a secondary is changed to primary while original primary is offline, wouldn't there be a brief period (after original primary is brought back online, but before I execute the hdrmksec.sh script) during which there are two primaries? Could that cause any issues? Thank you. DG "Nilesh Ozarkar" <nilesho@us.ibm.com> wrote in message news:mailman.1175.1212073853.20610.informix-list@iiug.org... > My second question, which was truncated as you suspected, quoted from a > later section of the Admin Guide where the procedure is described to > revert > the former-secondary-but-now-standard back to being a secondary, AND with > full resyncing of the (new) updates on the secondary back to the primary > (automatically and without re-initializing HDR). The procedure described > in > the documentation was quite simple: onmode -s on the former secondary > (that > would now be a standard), followed by onmode -d secondary <primary> (again > on the former secondary), followed by oninit (on the primary). (Assuming > logs haven't rolled over.) I think that procedure was described in Table > 48 > or 49. > > It sounded so perfectly desirable that I was licking my lips. > > So, the actual second question asked whether that section of the Admn > Guide > was something I could really count on. Or maybe I misunderstood. Or > maybe > the documentation wasn't really accurate. Yes - you can count on that, primary will get in sync with secondary (new updates).

informix-list-bounces@iiug.org wrote on 05/30/2008 03:26:22 AM: > Thank you, Mr. Ozarkar. > > Does the ability to "reverse sync" (replication updates from secondary back > to primary) depend at all on whether the secondary was changed (during the > period of primary outage) to Standard or Primary? Yes - reverse sync takes place only when secondary was changed to Standard. It won't happen when secondary was changed to primary. In later case, original primary will be brought up as secondary and log sync will happen as usual - from primary to secondary. > (I'm now trying to > understand the significance of Mr. Pruet's suggestion that it would be > advisable to change secondary to temporary primary, rather than temporary > standard.) > > Also, if a secondary is changed to primary while original primary is > offline, wouldn't there be a brief period (after original primary is brought > back online, but before I execute the hdrmksec.sh script) during which there > are two primaries? Could that cause any issues? No - hdrmksec.sh script will take care of that, there won't be two primaries. hdrmksec.sh will start the original primary in physical recovery and then it will change the server type to secondary, which will then get in sync with current primary. Hope that helps, Nilesh. > > Thank you. > > DG > > "Nilesh Ozarkar" <nilesho@us.ibm.com> wrote in message > news:mailman.1175.1212073853.20610.informix-list@iiug.org... > > My second question, which was truncated as you suspected, quoted from a > > later section of the Admin Guide where the procedure is described to > > revert > > the former-secondary-but-now-standard back to being a secondary, AND with > > full resyncing of the (new) updates on the secondary back to the primary > > (automatically and without re-initializing HDR). The procedure described > > in > > the documentation was quite simple: onmode -s on the former secondary > > (that > > would now be a standard), followed by onmode -d secondary <primary> (again > > on the former secondary), followed by oninit (on the primary). (Assuming > > logs haven't rolled over.) I think that procedure was described in Table > > 48 > > or 49. > > > > It sounded so perfectly desirable that I was licking my lips. > > > > So, the actual second question asked whether that section of the Admn > > Guide > > was something I could really count on. Or maybe I misunderstood. Or > > maybe > > the documentation wasn't really accurate. > > Yes - you can count on that, primary will get in sync with secondary (new > updates). > > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list

> -----Original Message----- > From: informix-list-bounces@iiug.org [mailto:informix-list- > bounces@iiug.org] On Behalf Of DGPretzel > Sent: Friday, May 30, 2008 1:26 AM > To: informix-list@iiug.org > Subject: Re: Two Questions on Restarting HDR (critical data undamaged) > > Thank you, Mr. Ozarkar. > > Does the ability to "reverse sync" (replication updates from secondary > back > to primary) depend at all on whether the secondary was changed (during > the > period of primary outage) to Standard or Primary? (I'm now trying to > understand the significance of Mr. Pruet's suggestion that it would be > advisable to change secondary to temporary primary, rather than > temporary > standard.) > > Also, if a secondary is changed to primary while original primary is > offline, wouldn't there be a brief period (after original primary is > brought > back online, but before I execute the hdrmksec.sh script) during which > there > are two primaries? Could that cause any issues? > > Thank you. > > DG > FWIW, this is how we handle the switchovers. We have been using HDR for several years now for a highly mission-critical db server. We have scripts set up to do the following, but these are the basics for a switchover: 1. on primary: -- switch to quiescent mode, in order to stop all txn traffic -- roll to next log (onmode -l), and force checkpoint (onmode -c), in order to force flush & sync w/ secondary -- stop replication via switch to std mode -- shut down instance 2. on secondary: -- switch to std mode Then AFTER any necessary repairs / work / etc. is all done, then we re-establish replication in the reverse direction via: 3. on (old) secondary: -- switch to primary mode 4. on (old) primary: -- bring up instance via "oninit -PHY" -- this goes thru physical recovery only, does NOT do logical recovery, and leaves the db instance ready to put into secondary mode -- switch to secondary mode To get replication back to the normal direction, we just go thru the above again, but with the roles reversed, of course. The reason that we opted NOT to go with the supplied HDRMK... scripts is that we do not always want the former secondary to be a primary right away. When a primary is up and its corresponding secondary server is not, the primary will periodically "ping" the secondary to see if it is up yet. We have had some cases where this caused interference when we were trying to troubleshoot the old primary. As I said, all of this stuff is scripted, and even partially automated to be executed by a 3rd "monitoring" box. Our reasoning on the standard-mode vs. primary-mode is that if the txn traffic was switched because of a problem on the primary, then we would like to troubleshoot that problem BEFORE we re-establish replication. The above scenario has been working out very well for us for several years, now. I did a presentation on all of this at the IIUG/IDUG 2006 N. America conference, if you want a bit more info. http://www.iiug.org/idug06/M10.pdf HTH, Paul M.