Re: HDR Reconstruction (with ER :-))

Keith, this is exactly the scenario described. As long as the logs on the remaining server have wrapped (ie the newest log on the down/recovered server is still online on the surviving server, then you can make this recovered server the secondary by running the onmode -s primary on the surviving server then starting the recovered server with -D -s (don't want anyone accidentally connecting to it before you make it a secondary - that would ruin everything) and running onmode -s secondary on the recovered server. When you have more downtime, you can swap roles using the swap scripts you mentioned. Note the procedure to make the surviving server (if it is the secondary) be the ER participant. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Nov 22, 2012 at 6:35 AM, Keith Simmons <smiley73@gmail.com> wrote: > Alexandre > > Thanks for this, but it doesn't cover the situation where the primary > fails so > secondary becomes primary, 'time passes' with transactions applied and > THEN the original primary becomes available and needs to be brought in > sync with the current primary before both can be switched back to their > original roles. > > Keith > > > On 22 November 2012 10:37, Alexandre Marini <alexandre@briug.org> wrote: > > Hello. > > It seems this link should answer your doubts (it´s in 11.70 Information > > Center, but doesn´t matter since you´re already using HDR+ER on your > > environment). > > > > > http://publib.boulder.ibm.com/infocenter/idshelp/v117/topic/com.ibm.erep.doc/ids_erp_159.htm?resultof=%22%68%64%72%22%20%22%66%61%69%6c%6f%76%65%72%22%20%22%66%61%69%6c%6f%76%22%20 > > > > > > Regards. > > > > Alexandre Marini > > IBM Informix Certified Professional v10 / v11.50 / v11.70 > > IBM Information Management Informix Technical Professional > > IBM Infosphere DataStage Technical Professional > > Informix Senior DBA - Orizon Brasil > > BRIUG website administrator > > Informix independent consultant > > > > > >> Date: Thu, 22 Nov 2012 09:38:14 +0000 > >> Subject: HDR Reconstruction (with ER :-)) > >> From: smiley73@gmail.com > >> To: informix-list@iiug.org > > > >> > >> Hi all > >> I am going to raise a case for this query but wanted to get some > community > >> feedback/thoughts. > >> Following on from a previous thread, I have an HDR pair acting as the > >> group > >> source for a source/target installation of ER (to a different IDS > version > >> on a > >> different OS). > >> I can see why ER should be suspended if HDR fails to confirm updates on > >> the secondary (a nuisance but understandable). What is of more concern > is > >> f one of the HDR pair is unavailable for an extended length of time > (more > >> than > >> a few minutes but less than the time taken to cycle the logs (currently > 30 > >> hours)). > >> I cannot afford to have the ER target not being updated for this length > of > >> time > >> so would (apparently) have no choice but to put the remaining HDR server > >> into standard mode in order to get ER transactions transferring. However > >> once the HDR pairing is broken like this I apparently have to re-create > it > >> by > >> shipping a full archive to the secondary again, physically restoring and > >> rolling > >> in logs. This is time-consuming and expensive when the database is > >> approaching 800Gb, the servers are 100 miles apart and same-day courier > >> of tapes is the only sensible way. > >> I've been testing the swap of the HDR servers between primary and > >> secondary (using the supplied scripts hdrmkpri.sh and hdrmksec.sh) and > >> have observed that during this procedure each of the servers is made > >> standard. The primary is then made into primary and the secondary to > >> secondary without using an archive restore but rather an undocumented > >> (except in this script !!) flag for oninit. > >> My thought is that, as long as both databases were originally an HDR > pair, > >> that logs have not cycled and neither database has required a restore, > >> starting from both databases in standard mode can I switch one to > primary, > >> stop the other and restart using the undocumented flag (which would seem > >> to force the engine into a physical restore state) and then switch it to > >> secondary. > >> This 'feels' like it should work but I would appreciate any thoughts. I > am > >> also hoping to get a test environment of this set up shortly to try > this. > >> Many thnaks > >> Keith > >> _______________________________________________ > >> Informix-list mailing list > >> Informix-list@iiug.org > >> http://www.iiug.org/mailman/listinfo/informix-list > > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > >