Re: HDR Reconstruction (with ER :-))

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