Migrating the Primary

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 reasons such as maintenance or to make the application active on another node.

In the following illustration, the Primary seattle is replicating to the Secondary hosts london and tokyo.

Click the thumbnail above to view full-sized image.

In the following illustration, the Primary role has been migrated from seattle to london and the new Primary london is replicating to seattle and tokyo. If you had already created RLINKs between london and tokyo when setting up replication, you do not need to manually reconfigure the additional Secondary tokyo as a part of the RDS. It will automatically be added as a Secondary of the new Primary london.

Click the thumbnail above to view full-sized image.

VVR provides the vradmin migrate command to migrate a healthy Primary. The vradmin migrate command performs the following functions:

• Migrates the Primary role of an RDS to a Secondary, thus converting the Secondary RVG to the Primary RVG.
• Converts the original Primary of the RDS to Secondary in the RDS.
• Reconfigures the original Primary and the new Primary.

The vradmin migrate command restores the original configuration if it fails on any of the hosts during its execution.

Before migrating the Primary role, the vradmin migrate command displays a warning and prompts the user to confirm whether or not all the applications using the Primary volumes are stopped. To skip this confirmation, use the -s option with the vradmin migrate command, which proves useful in scripts.

Prerequisites for migrating the Primary:

  The data volumes in the RDS must be inactive, that is, applications that use the Primary data volumes must be stopped.

  All Secondaries must be up-to-date.

  All attached RLINKs must be in the CONNECT state.

To migrate a healthy Primary from any host in an RDS:

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

The argument newprimary_name is the name of the new Primary host, that is, the existing Secondary host. For an RDS with only one Secondary, this argument is optional. Note that the newprimary_name argument must be the host name displayed by the vradmin printrvg command.

Important Notes for Migrating the Primary Role

• We recommend that you set the size of the SRL the same on the Primary and Secondary nodes because any of the Secondary nodes could be later converted to a Primary by using the vradmin migrate or the vradmin takeover command.
• We recommend that you configure the Primary and Secondary data volumes with the same names. However, if the names of the data volumes on the Primary and the Secondary do not match, map the names of the Secondary data volumes with the differently named Primary data volumes. For more information, see Mapping the Name of a Secondary Data Volume to a Differently Named Primary Data Volume.
• For an RDS with multiple Secondaries:
• We recommend that you wait until all the Secondaries are up-to-date before migrating the Primary role. The vradmin migrate command fails if all the Secondaries are not up-to-date. If the additional Secondaries were out of date before performing the migrate operation, then you would need to perform a complete synchronization.
• After successful migration, if you had already created RLINKs between every pair of secondaries while setting up replication, you do not need to manually reconfigure the additional secondaries as a part of the RDS. Otherwise, you must reconfigure them manually. For more information, see Example 2---Migrating the Primary Role in a Setup with Multiple Secondaries.

Example 1---Migrating from a Healthy Primary

This example explains how to migrate the original Primary seattle to the Secondary host london.

Before migration, the configuration of the RDS looks like this:

After the migration, the configuration of the RDS looks like this:

  To migrate the Primary RVG hr_rvg to host london:

1. Stop the applications that use the Primary data volumes. For example, if the application is a file system, unmount it.
2. Verify that the Primary RLINK is up-to-date by using the vxrlink status command. On the Primary seattle, issue the following command:
     # vxrlink -g hrdg status rlk_london_hr_rvg

   The vradmin migrate command fails if the Primary RLINK is not up-to-date or not in the CONNECT state. It also fails if the data volumes are active.

3. Migrate the Primary RVG hr_rvg by typing the following command from any host in the RDS:
      # vradmin -g hrdg migrate hr_rvg london

   london is the name of the Secondary host displayed by the vradmin printrvg command.

4. Restart the application.

   Because the application was stopped properly before the migration, an application recovery is not required.

   By default, the vradmin migrate command enables replication from the new Primary london. To start the application before enabling replication, first, issue the vradmin pauserep command, start the application, and then resume replication.

Example 2---Migrating the Primary Role in a Setup with Multiple Secondaries

We recommend that you create RLINKs between hosts london and tokyo when setting up the RDS.

Before migration, the configuration of the RDS looks like this:

  To migrate the Primary RVG hr_rvg to host london:

1. Stop the applications that use the Primary data volumes. For example, if the application is a file system, unmount it.
2. Verify that the Primary RLINKs are up-to-date by using the vxrlink status command. On the Primary seattle, issue the following commands:
     # vxrlink -g hrdg status rlk_london_hr_rvg
     # vxrlink -g hrdg status rlk_tokyo_hr_rvg

   The vradmin migrate command fails if the Primary RLINKs are not up-to-date or not in the CONNECT state. It also fails if the data volumes are active.

3. Migrate the Primary RVG hr_rvg by typing the following command from any host in the RDS:
      # vradmin -g hrdg migrate hr_rvg london
4. If you had created RLINKs between the Secondary london and the additional Secondary tokyo, host tokyo is automatically added to the new configuration.

   Otherwise, you must manually add tokyo as a Secondary to the new Primary london. To do this, create RLINKs between london and tokyo and associate them to the respective RVGs using the following commands.

   On host london:

   
   # vxmake -g hrdg rlink rlk_tokyo_hr_rvg local_host=london \
       remote_host=tokyo remote_rlink=rlk_london_hr_rvg \
        remote_dg=hrdg
   # vxrlink -g hrdg assoc hr_rvg rlk_tokyo_hr_rvg

   On host tokyo:

   
   # vxmake -g hrdg rlink rlk_london_hr_rvg local_host=tokyo \
       remote_host=london remote_rlink=rlk_tokyo_hr_rvg \
        remote_dg=hrdg
   
   # vxrlink -g hrdg assoc hr_rvg rlk_london_hr_rvg

   ---

     Note    By default, the vxmake rlink command creates the RLINK with the protocol set to UDP/IP. To change the protocol to TCP/IP, see Setting the Network Transport Protocol.

   ---

5. Start replication to tokyo using the following command:
      # vradmin -g hrdg -f startrep hr_rvg tokyo

   ---

     Note    Ensure that the above command is run before starting the application on the new Primary london.

   ---

6. Restart the application.

   Because the application was stopped properly before the migration, an application recovery is not required.

   By default, the vradmin migrate command enables replication from the new Primary london. To start the application before enabling replication, first, issue the vradmin pauserep command, start the application, and then resume replication.

After migration, the configuration of the RDS looks like this: