Failing Back to the Original Primary

After an unexpected failure, the original Primary host might become available and find that one of its Secondary hosts has been promoted to a Primary as a result of a takeover. A takeover happens when a Secondary of the original Primary takes over the Primary role because of an unexpected outage of the original Primary. The process of transferring the Primary role back to the original Primary is called failback.

VVR VEA provides the following methods to fail back to the original Primary:

• Failing Back Using Fast-Failback Synchronization
• Failing Back Using Automatic Synchronization

---

  Note    It is recommended that you use the fast-failback synchronization method.

---

The fast-failback synchronization method can be used when the Fast failback option is selected during Takeover.

If you are sure that the original Primary will not recover or if most of the data on the new Primary is going to change while the original Primary is unavailable, you must synchronize the Secondary completely. In this case, you must failback using automatic synchronization. For details about failing back to the original Primary, refer to Failing Back to the Original Primary.

Failing Back Using Fast-Failback Synchronization

To use the fast-failback synchronization method to fail back to the original Primary, the fast-failback feature must be enabled when taking over the Primary role.

For more information about the fast-failback feature, see the Chapter 7, "Transferring the Primary Role" in the VERITAS Volume Replicator Administrator's Guide.

  To fail back to the original Primary using fast-failback synchronization

1. If Auto fast failback is selected in the Takeover dialog box during the takeover, go to step 3; otherwise go to the next step.
2. If Fast failback was selected in the Takeover dialog box during the takeover, synchronize the data volumes on the original Primary, which is now the new Secondary, with the data volumes on the new Primary using the Replay Failback Log task (Replication > Replay Failback Log).
3. After the replay completes, stop the application on the new Primary at a scheduled time.
4. Migrate the Primary Role to the original or failed Primary. For instructions, see Migrating the Primary Role.

Example---Failing Back to the Original Primary Using Fast Failback

In this example, the Primary host seattle has restarted after an unexpected failure. After the failure, the Primary role was taken over by the Secondary host london. Each data volume on the Secondary london has a Data Change Map (DCM) associated with it.

This example explains how to failback when fast failback is enabled on london by selecting Auto fast failback in the Takeover wizard or when Fast failback was selected.

An application is running on london and incoming writes are logged to its DCM. This example shows how to fail back to the original Primary seattle using the fast-failback feature.

  To fail back to the original Primary using fast failback

1. If Auto fast failback was selected in the Takeover task when taking over from the original Primary seattle, go to step 5; If Fast failback was selected, go to the next step.
2. From the tree view, select the name of the RDS for which you want to replay the failback log. For example, hr_rvg.
3. Choose Replication > Replay Failback Log. To use the pop-up menu, right-click the name of the RDS.
4. Click OK. When the synchronization completes, go to the next step. You can check the status of the synchronization using the RDS view.

   The Replay Failback Log task synchronizes the data volumes in the new Secondary RVG hr_rvg on seattle with the data volumes in the new Primary RVG hr_rvg on london using the fast-failback feature. This step is not required if Auto fast failback was selected in the Takeover task when taking over from the original Primary.

5. At a convenient time, after verifying that the synchronization has completed, stop the application on the new Primary london.
6. Migrate the Primary role from the new Primary host london to the original Primary host seattle using the Migrate task (Replication > Migrate). For instructions, see Migrating the Primary Role.

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

Failing Back Using Automatic Synchronization

  To fail back to the original Primary using automatic synchronization

1. Convert the original Primary to a Secondary using the Make Secondary task (Replication > Make Secondary).

   For detailed instructions, see Converting a Primary to a Secondary.

2. Synchronize the data volumes on the original Primary with the data volumes on the new Primary using the Synchronize RVG task (Replication > Synchronize RVG).

   For detailed instructions, see Synchronize the Secondary RVG with the Primary RVG.

3. Stop the application on the new Primary.
4. Migrate the Primary role from the new Primary host to the original Primary host. Replication from the original Primary to the original Secondary is started by default. See Migrating the Primary Role.

Converting a Primary to a Secondary

Use the Make Secondary task to convert an original Primary to a Secondary. The Make Secondary task can be launched from the original Primary only when one of its Secondary hosts has taken over the Primary role.

The Make Secondary task is used in the failback procedure to fail back to the original Primary. When the original Primary restarts, use the Make Secondary task to convert the original Primary to a new Secondary. Stop the application if the application restarts automatically when the Primary restarts.

  To convert an original Primary to a Secondary

1. From the tree view, select the name of the original Primary host that has restarted and whose role you want to convert to Secondary. For example, seattle.
2. Choose Replication > Make Secondary. To use the pop-up menu, right-click the name of the RDS.
3. Complete the Make Secondary dialog box as follows:

   New Primary

   From the drop-down list, select the name of the new Primary. For example, london. If the original Primary no longer has a list of its original Secondary hosts, then enter the name in the box that is provided. The value in the entry field takes precedence over the selected value in the selection box.

4. Click OK. A message that indicates whether the Make Secondary task succeeded or failed is displayed.

   Notes:
   Before using the Make Secondary task, make sure that you stop all the applications that use the data volumes on the original Primary. Also, ensure that none of the data volumes are open.

Synchronize the Secondary RVG with the Primary RVG

Use the Synchronize RVG task to synchronize the data volumes on the Secondary with the data volumes on the Primary. The Synchronize RVG task can be used in the failback procedure to synchronize the data volumes on the original Primary with the data volumes on the new Primary using automatic synchronization.

  To synchronize the Secondary RVG with the Primary RVG

1. Select the Secondary host name from the tree view.
2. Choose Replication > Synchronize RVG.
3. Click OK. The status of the synchronization is displayed in a message box.

   Note:
   While resynchronization is in progress, the RDS View displays the values resync in progress and DCM (autosync) in the Replication Status and Logging To columns respectively.

Example: Failing Back Using Automatic Synchronization

In this example, the Primary host seattle has restarted after an unexpected failure. After the failure, the Secondary host london has manually taken over the Primary role. This example shows how to fail back to the original Primary seattle using automatic synchronization.

  To fail back using automatic synchronization

1. From the tree view, select the name of original Primary host, seattle, which has restarted and whose role you want to convert to Secondary.
2. Choose Replication > Make Secondary. To use the pop-up menu, right-click the name of the RDS.
3. In the Make Secondary box, select or enter london in the New Primary box. For detailed instructions, see Converting a Primary to a Secondary.

   The Make Secondary task converts the original Primary RVG hr_rvg on seattle to the Secondary RVG of the new Primary london.

4. Select the Secondary host name seattle from the tree view.
5. Choose Replication > Synchronize RVG. For detailed instructions, see Synchronize the Secondary RVG with the Primary RVG.

   The Synchronize RVG task synchronizes the data volumes in the RVG hr_rvg on seattle with the data volumes on the new Primary RVG hr_rvg on london using automatic synchronization.

6. Stop the applications on the new Primary london.
7. Migrate the Primary role from the new Primary host london to the original Primary host seattle using the Migrate wizard (Replication > Migrate). For instructions, see Migrating the Primary Role. Replication from the original Primary seattle to the original Secondary london is started by default after the migration is completed.