Re: HDR Reconstruction (with ER :-))

On Thursday, November 22, 2012 3:39:21 AM UTC-6, Keith Simmons wrote: > 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 What version are you on? We put code in the more recent versions of the server so that as soon as the HDR pair was broken (based on the HDR PING TIMEOUT), then ER would continue without waiting for the HDR ack. I suspect this addresses your issue. Contact tech support for more details.

Madison Thanks, IDS 9.4 :-(( at the moment but looking to upgrade Q1/2013 so will be much happier then. I assume this is in 11.7 latest and greatest, I will check the release notes. Keith On 29 November 2012 02:29, mpruet <mpruet@us.ibm.com> wrote: > On Thursday, November 22, 2012 3:39:21 AM UTC-6, Keith Simmons wrote: > > 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 > > What version are you on? > > We put code in the more recent versions of the server so that as soon as > the HDR pair was broken (based on the HDR PING TIMEOUT), then ER would > continue without waiting for the HDR ack. I suspect this addresses your > issue. Contact tech support for more details. > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list >