FYI: I was assuming that the crash was of the type that would require a
rebuild of the dbspaces on the primary IE: catastrophic disk failure,
etc. or that the primary was down long enough that the secondary (now a
standard mode engine) had rolled over its logs, meaning that the primary
wouldn't be able to recover that way. I wouldn't expect anyone to go
and restore a backup they didn't need to.
Also, I've never managed to restart replication after the primary
required a restore without restoring the secondary as well (it seems to
hang up on the type exchange), but at least the primary can be running
while the secondary is reading the tape.
--EEM
-----Original Message-----
From: Francisco Roldan [mailto:froldan (AT) 5b (DOT) com.gt]
Sent: Friday, September 12, 2003 5:05 PM
To: Everett Mills; antzz; informix-list (AT) iiug (DOT) org
Subject: RE: HDR Failure Scenario
It sounds logic,
I guess it works,
trying to get a shorter period of recovery time,
would it be possible to skip step 4 ?
In that point both servers would have the same data,
I think that in this moment, it would only need steps 5 and 6 :
5) Do onmode -d primary <sec_name> on Primary.
6) Do onmode -d secondary <pri_name> on Secondary.
7) Logs are then sent to Secondary and HDR starts.
But I don't know if HDR would require the physical restore ...
Until now I haven't had a database crash since I implemented HDR ,
I could try it on my next chance when i get a crash ... , (I hope not
soon
.... )
What do you think ?
-----Mensaje original-----
De: Everett Mills [mailto:eemills (AT) nationalbeef (DOT) com]
Enviado el: Jueves, 11 de Septiembre de 2003 11:14 a.m.
Para: antzz; informix-list (AT) iiug (DOT) org
Asunto: RE: HDR Failure Scenario
Why not just restore the same backup to both boxes, it would save a
considerable amount of time. Also, you would probably want to not
change
the primary off of standard until the restore is done on the secondary.
That way the primary won't be wasting a lot of time trying to connect.
1) Primary goes down.
2) Secondary is changed to standard and then backed up.
3) Backup is then restored to the Primary.
4) Do ontape -p on Secondary.
5) Do onmode -d primary <sec_name> on Primary.
6) Do onmode -d secondary <pri_name> on Secondary.
7) Logs are then sent to Secondary and HDR starts.
If you want the secondary to be active until the primary is completely
restored, you will also need to backup the logs on the secondary (ontape
-a) and restore them to the primary (ontape -l) just before you issue
the
oninit command.
The manual says that logs on the secondary can be pushed back to the
primary
after a failure, but I've never gotten that to work.
--EEM
-----Original Message-----
From: antzz [mailto:member37779 (AT) dbforums (DOT) com]
Sent: Thursday, September 11, 2003 9:32 AM
To: informix-list (AT) iiug (DOT) org
Subject: HDR Failure Scenario
I would like to know if the following scenario will work (or whether
it's
feasible):
1) Primary goes down.
2) Secondary is changed to standard and then backed up.
3) Backup is then restored to the Primary.
4) Do Backup of primary again.
5) Do onmode -d primary <sec_name> on Primary.
6) Do ontape -p on Secondary.
7) Do onmode -d secondary <pri_name> on Secondary.
8) Logs are then sent to Secondary and HDR starts.
I would like to test this scenario because I know the Secondary contains
the
most up-to-date transactions ( Rather than relying on the Secondary
sending
them over the network to the Primary after I restore the latest backup
to
the Primary - this is the normal Disaster Recovery Process as prescribed
by
the Informix Admin Guide).
As for my scenario above, do I really need to do steps 4 and 6(i.e.
Primary
backup and Secondary Restore since I got the latest backup from the
Secondary anyway - i.e. will the Secondary complain if I make it into a
Secondary again without doing a restore?)
Any opinions appreciated. Thanks.
--
Posted via http://dbforums.com
sending to informix-list
sending to informix-list
HDR Failure Scenario -
09-11-2003
, 09:32 AM
Linear Mode
