Volume Replicator 7.4.2 Administrator's Guide - Windows

Performing a takeover using the fast-failback option

In the case of a Primary failure or if the Primary needs to be brought down for some maintenance tasks, the role of the Primary needs to be taken over by the Secondary. When the old (original) Primary comes up you can failback from the new Primary to the original Primary. The fast-failback feature enables you to do this quickly and efficiently as it performs incremental synchronization, for only the changed data. This feature uses the DCMs of the data volumes of the new Primary, to keep track of the changed content and the new content. This process of logging on the DCM is called failback logging.

You can perform the takeover operation with fast-failback by selecting the failback logging option on one of the Secondaries. After the takeover operation is complete the applications are started on the new Primary. All the subsequent writes from the applications running on the new Primary are then tracked on the DCM of the new Primary. When the original Primary recovers, it discovers that one of its Secondaries has taken over as the new Primary and it starts acting as a Secondary. The synchronization to the original Primary can be started manually or automatically depending on the options that are specified during takeover. The RVG volumes on the original Primary disallow access permissions to the applications and need to be synchronized with the new Primary by playing back the DCM. You need to perform the resynchronization operation to start the DCM replay. At the start of the DCM replay, the original Primary becomes a Secondary and starts receiving the missing updates.

You can then continue to use the current setup after takeover, as is, or, you can complete the failback process by using the migrate operation to change the Primary role back to the original Primary. If you want to migrate the role of Primary back to the original Primary then you do not need to perform the operation to add the other Secondaries back to the original Primary. The RLINKs from the other Secondaries to the original Primary are still retained, and once the Primary role is migrated back to the original Primary (current Secondary) these Secondaries automatically become Secondary hosts to the original Primary.