Symantec logo

Important notes about taking over from an original Primary

The vradmin takeover command performs the following functions on the RDS to which the original Primary belongs:

About fast failback

The applications are started on the new Primary after the takeover is complete. The fast failback feature uses failback logging for incremental synchronization of the original Primary with the new Primary. Fast failback works by keeping track of the incoming writes to the new Primary and the writes to the original Primary that did not reach the Secondary before the original Primary failed. Based on the tracked writes, data can be transferred to the original Primary after it recovers. This eliminates the need to completely resynchronize the original Primary with the new Primary after the original Primary recovers; only the changed blocks are resynchronized. Fast failback uses DCMs on the new Primary to track the changed blocks.

To enable fast failback, each data volume on the Secondary must have an associated DCM. The takeover command enables fast failback on the new Primary by activating the DCM. The DCM is later used to synchronize the data volumes on the original Primary with the data volumes on the new Primary.

When the original Primary recovers, it needs to be synchronized with the new Primary by playing back the DCM on the new Primary. To receive the missing updates, the original Primary must first be converted to a Secondary. The new Primary can then begin DCM playback to the original Primary. This process can be initiated automatically upon recovery of the original Primary by using the -autofb option to the takeover command, or it can be initiated manually at some later time by using the vradmin fbsync command.

When you use the -autofb option with the vradmin takeover command, it automatically synchronizes the original Primary when it becomes available. The -autofb option converts the original Primary to a Secondary after it comes up and also uses the DCM to synchronize the data volumes on the original Primary using fast failback. The -autofb option can be used only if each Secondary data volume has an associated DCM.

If you prefer not to have the original Primary automatically converted to a secondary upon reboot, the process can be performed manually using the vradmin fbsync command.

To change the role from Secondary to Primary without enabling fast failback, use the -N option with the vradmin takeover command. Use the -N option if you are sure that the original Primary will not recover or if most of the data on the Primary is going to change while the Primary is down. When performing vradmin takeover with the -N option the command automatically detaches the RLINKs from the old Primary to the new Primary. This requires either difference-based synchronization (vradmin syncrvg) or full synchronization of the data volumes on the original Primary.


To take over from the Primary RVG hr_rvg on host seattle to the Secondary RVG hr_rvg on host london, make sure that the data volumes on the Secondary have associated DCMs. Use the following command to check that the LOGONLY attribute is set for the data volumes:

# vxprint -g hrdg -ht hr_rvg

We recommend that you use the fast failback synchronization method to synchronize the original Primary with the new Primary. For details, see Failing back using fast failback synchronization.

For an RDS with multiple Secondaries, after take over, VVR automatically reconfigures any additional Secondaries as Secondaries of the new Primary, if RLINKs had been created between the Secondaries. Otherwise, you must manually reconfigure them. For more information, see Example 2—Taking over from an original Primary in a setup with multiple Secondaries.

To take over an original Primary with fast failback enabled (default), issue the following command on the Secondary that is to take over the Primary role:

# vradmin -g diskgroup takeover local_rvgname

The argument diskgroup is the disk group on the local host.

The argument local_rvgname is the name of the RVG on the local host.