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.

See Synchronizing volumes using difference-based synchronization.

To fail back to the original Primary seattle using difference-based synchronization

  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.