When disaster strikes and the Primary host goes down, the Secondary can be updated using the bunker. as described in this section.
Note If the Primary SRL has overflowed for a Secondary, or if the Secondary is inconsistent because it is resynchronizing, you cannot use the corresponding bunker SRL to recover the Secondary. Because the bunker does not have data volumes, it cannot use DCM to track overflows.
VVR commands relating to bunker replication can be issued on any VVR host associated to the RDS, except where indicated. The
deactivatebunker commands must be issued on the bunker host.
To update the Secondary from the bunker
STORAGEprotocol, import the disk group containing the bunker SRL onto the bunker host and then recover it. Issue the following commands on the bunker host:
vxdg -C import hrdg2
vxrecover -g hrdg2 -ns
vradmin -g hrdg2 activatebunker hr_rvg
This command converts the bunker RVG from receiving mode (Secondary) to replicating mode (Primary).
You only need to issue the
activatebunker command once, even if you are updating multiple Secondaries.
vradmin -g hrdg2 -b startrep hr_rvg london
This command connects the RLINKs that were created when the bunker was added to the RDS and begins replaying the bunker SRL.
If you have more than one Secondary using this bunker, repeat the
startrep command for each Secondary.
vradmin -g hrdg2 repstatus hr_rvg
vradmin -g hrdg2 stoprep hr_rvg london
Note Deactivate the bunker only after all the replays from the bunker have been stopped.
To deactivate the bunker, issue the following command on the bunker host:
vradmin -g hrdg2 deactivatebunker hr_rvg
You only need to issue this command once.
The Secondary is now up-to-date and can take over as Primary. For details on the take over process, see Taking over from an original Primary.