Using the Bunker node to update the Secondary

If your setup is configured for Bunker replication and a disaster occurs at the Primary site, you can use the Bunker node to update the Secondary. Because replication to Bunker node is synchronous, the writes that are written to the Primary are simultaneously written to the Bunker, therefore the Bunker node does not lag behind and enables zero RPO. Before you start the replay, activate the Bunker node to convert it to a Bunker Primary. Then start replication on the Secondary so that any pending updates that did not reach the Secondary are sent to the Secondary from the Bunker node. After all the updates have been sent to the Secondary, you can verify the status of the Secondary using the vxrlink status command.

Note:

If the Primary Replicator Log has overflowed for a Secondary, or if the Secondary is inconsistent because it is resynchronizing, you cannot use the corresponding Bunker Replicator Log to recover the Secondary. Because the Bunker node does not have data volumes, it cannot use DCM to track overflows. By default, the Replicator Log protection for the RLINK between the Primary and the Bunker is set to off.

After all the updates have been sent to the Secondary, you can stop replication and then perform takeover on the up-to-date Secondary. Before takeover, you must deactivate the Bunker to convert it back to a Bunker Secondary. If you plan to continue using the original Secondary as a Primary, you cannot use the Bunker of the original Primary as a Bunker to the new Primary. You must configure a new Bunker host.