Migrating the Primary to a Secondary

Last published : Jun 12, 2026
Use the vxrds migrate command to interchange the Primary role with the specified Secondary. The new_Primary_hostname parameter specifies the Secondary host. The Primary role can only be migrated when the Secondary is active, consistent, and up-to-date. The data volumes in the RDS must be inactive, that is, the applications that are involved in replication must be stopped before you run the vxrds migrate command. After the migration is complete, the Primary and Secondary roles are interchanged.
If the original Primary has multiple Secondary hosts, and the RLINKs between every pair of Secondaries have not been created, then, after migrating the Primary role to one of the Secondaries or performing takeover on one of the Secondaries, all the remaining Secondaries in the RDS become orphan. You must manually delete these Secondaries and then again add them as Secondaries to the new Primary.
However, if RLINKs have been created between each pair of Secondaries in the RDS, then following steps can be used after migrate or takeover operation to add the orphaned Secondaries back in the RDS.
Syntax for vxrds migrate command:
vxrds [-g <diskgroup>] migrate [-attachallsites] <local_rvg> <new_Primary_hostname>
Example:
vxrds -g vvrdg migrate rvg sec_host
In case of multiple Secondaries, if the -attachallsites flag is used, the RVGPrimary agent:
  • Verifies that all the Primary RLINKs are up-to-date and only then lets the migrate operation proceed.
  • Forcefully attaches all the Secondaries to the new Primary without any data synchronization.
See RVGPrimary agent-specific functions, state definitions, and attributes.
To migrate the Primary to a Secondary
  1. On each orphaned Secondary host, detach the RLINK on this orphan Secondary pointing to the original Primary (the Primary host before migrate or takeover).
The orphan Secondaries join the RDS of the new Primary.
  1. Start replication with Automatic Synchronization on each of these orphans.
  2. Alternatively, you can use the vxrsync utility to bring the Secondaries up-to-date. To do this, Start a checkpoint using the Start Checkpoint option. Use the vxrsync utility to perform difference-based synchronization to the Secondaries from the new Primary host.
After the synchronization completes, End the checkpoint using the End Checkpoint option.
Select the Synchronize from Checkpoint option to start replication from checkpoint to synchronize the Secondary with the writes that happened when vxrsync was in progress
Because the RLINKs for the other Secondary hosts are still associated you do not need to use the vxrds addsec command to add the existing Secondary hosts to the new Primary after the migrate or takeover operation.
You can choose to perform Automatic Synchronization or difference-based synchronization depending on the amount of the data that exists on the volumes. For example, if you have large volumes, but the actual data on it is very small, then Automatic Synchronization can be used as the intellisync option synchronizes only those bits of data that changed. However, if you have large amounts of data with comparable changes then the vxrsync difference-based synchronization is a better option.
If the RVG is part of a VCS cluster and the RVGPrimary resource for the Primary RVG exists, then Volume Replicator fails the vxrvg migrate command for this RVG.