< Previous  | TOC | Index | Next  >

Migrating the Primary role

Migration involves transferring a healthy Primary of a Replicated Data Set (RDS) to a Secondary when the application involved in replication is inactive. Migration of a Primary to a Secondary is useful when the Primary must be brought down for maintenance or to make the application active on another node.

Use the Migrate task to migrate the role of a healthy Primary to a specified Secondary. The Migrate task performs the following functions:

• Migrates the Primary role of an RDS to the Secondary RVG.
• Converts the Secondary RVG to the Primary RVG.
• Converts the original Primary of the RDS to Secondary in the RDS.
• Reconfigures only the original Primary and the new Primary.

For details about migrating the Primary role, refer to Transferring the Primary role.

 To migrate a healthy Primary

1. Stop all the applications that are involved in replication. For example, if the application is a file system, unmount it.
2. Verify that the Secondaries are up to date by checking the RDS view. In the RDS View, the Data Status of the Secondary must be consistent, up to date and the Replication Status must be connected (replicating).
3. From the tree view, select the name of Secondary host whose role you want to change. For example, london.
4. Choose Replication > Migrate. To use the pop-up menu, right-click the name of the RDS.
5. In the Migrate Primary Role dialog box, click OK. A message that indicates whether the migration succeeded or failed is displayed.

    

   Notes:
   The Migrate task fails if the active Secondaries are not up to date and if the data volumes are active. By default, the Migrate task starts replication from the new Primary to the original Primary. If an RDS contains multiple Secondaries, VVR VEA does not automatically reconfigure the additional Secondaries. If required, you can reconfigure the additional Secondaries as Secondary hosts of the new Primary using the VVR command-line interface. The Data Status of the Secondary (attached RLINKs) must be consistent, up to date and the Replication Status must be connected (replicating). If the Migrate task fails on any of the hosts, the original configuration is restored. On migration, the Secondary becomes the new Primary. Because the application was stopped before the migration, an application recovery is not required. To start the application before enabling replication after migration, first, pause replication using the Pause task (Replication > Pause), start the application, and then resume replication using the Resume task (Replication > Resume).