< Previous  | TOC | Index | Next  >

Failing back using difference-based synchronization

Failing back to the original Primary using difference-based synchronization involves the following steps:

1. Converting the original Primary to a Secondary of the new Primary.
2. Synchronizing the data volumes on the original Primary with the data volumes on the new Primary using difference-based synchronization using checkpoint.
3. Starting replication to the Secondary (original Primary) using checkpoint.
4. Migrating the Primary Role to the original Primary and starting replication by default.

The examples in the following section explain how to fail back to the original Primary using VVR.

Converting an original Primary to a Secondary

VVR provides the vradmin makesec command to convert the original Primary to a Secondary. This command is only needed if fast failback was not enabled when the original takeover was performed. If fast failback was enabled, the original Primary will automatically be converted to a Secondary when DCM playback begins. Note that this command can be run only from the original Primary host where one of its original Secondaries has taken over the Primary role.

You can issue the vradmin makesec command in the failback procedure only if fast failback has not been enabled when taking over from the original Primary. Run this command when the original Primary restarts. Stop the application if it restarts automatically when the Primary restarts. The vradmin makesec command converts the original Primary to a Secondary RVG.

  Tip   Before using the vradmin makesec command make sure you close all the applications running on the original Primary's data volumes. Also ensure that none of the data volumes are open.

The vradmin makesec command fails if the Secondary data volumes are not up-to-date or if there are some applications still running on the failed Primary's data volumes. Use the -f option to convert a failed Primary to a Secondary even when the Secondary data volumes are not up-to-date. If any of the failed Primary data volumes are open or have applications running on them, then using the vradmin makesec command with the -f option will fail. To proceed with the vradmin makesec command, first close the volumes or stop the applications as required.

To convert an original Primary to a Secondary:

# vradmin -g diskgroup makesec local_rvgname newprimary_name

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, that is, the original Primary and represents its RDS.

The argument newprimary_name is the name of the new Primary host, that is, the previous Secondary host. Note that the newprimary_name argument must be the same as the host name displayed with the Primary-Primary configuration error in the output of the vradmin -l printrvg command.

Example 3—Failing back to the original Primary Using
Difference-based synchronization

In this example, the Primary host seattle has restarted after an unexpected failure. After the failure, the original Primary seattle has been manually taken over by the Secondary host london. This example shows how to fail back to the original Primary seattle using difference-based synchronization. For more information, see Synchronizing volumes using difference-based synchronization.

 To fail back to the original Primary seattle

1. Make the original Primary RVG hr_rvg on seattle the Secondary RVG of the new Primary london by typing the following command on the original Primary seattle:

# vradmin -g hrdg makesec hr_rvg london

2. Synchronize the data volumes in the original Primary RVG hr_rvg with the data volumes in the new Primary RVG hr_rvg on london using the difference-based synchronization and checkpoint. To synchronize the Secondary based on differences using a checkpoint, type the following command on any host in the RDS:

# vradmin -g hrdg -c checkpt_presync syncrvg hr_rvg seattle

3. Stop the application on the new Primary london.
4. Start replication to the Secondary RVG (original Primary) hr_rvg on seattle from the new Primary RVG hr_rvg on london using the checkpoint by typing the following command on any host in the RDS:

# vradmin -g hrdg -c checkpt_presync startrep hr_rvg seattle

5. Migrate the Primary role from the new Primary host london to the original Primary host seattle by typing the following command on any host in the RDS:

# vradmin -g hrdg migrate hr_rvg seattle

Replication from the original Primary seattle to the original Secondary london is started by default.

6. Restart the application on the original Primary seattle. Because the application was stopped properly before the migration, an application recovery is not required.

Example 4—Failing back to the original Primary using difference-based synchronization in a multiple Secondaries setup

This example shows how to fail back to the original Primary seattle using the difference-based synchronization feature.

1. Perform step 1 to step 5 described in the example Example 3—Failing back to the original Primary Using Difference-based synchronization.
2. On the original Primary seattle:
   • Synchronize the data volumes in the Secondary RVG hr_rvg on tokyo with the data volumes in the original Primary RVG hr_rvg using the difference-based synchronization and checkpoint. To do this, use the following command on any host in the RDS:

# vradmin -g hrdg -c checkpt syncrvg hr_rvg tokyo

The -c option when used with the vradmin syncrvg command automatically starts a checkpoint with the specified name, checkpt, in this example. After the data volumes are synchronized, the checkpoint is ended.

• Start replication from seattle to tokyo using the command:

# vradmin -g hrdg -c checkpt startrep hr_rvg tokyo

3. Restart the application on the original Primary seattle. Because the application was stopped properly before the migration, an application recovery is not required.