Failing Back to the Original Primary

After an unexpected failure, a failed 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.

VRW provides the following methods to fail back to the original Primary:

• Failing Back Using Fast-Failback Synchronization
• Failing Back Using Difference-Based Synchronization

---

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

---

For a comparison of fast failback versus difference-based synchronization, see the VERITAS Volume Replicator Administrator's Guide.

Failing Back Using Fast-Failback Synchronization

Before using the fast-failback synchronization method to fail back to the original Primary, verify whether the fast-failback feature was enabled when taking over the Primary role. For more information about the fast-failback feature, see the chapter "Transferring the Primary Role" in the VERITAS Volume Replicator Administrator's Guide.

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

1. 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 dialog box (Change Role > Replay Failback Log). Do not perform this step if Auto-fast failback is selected in the Takeover dialog box during the takeover.
2. Stop the application on the new Primary.
3. 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 and fast failback is enabled on london by selecting the Auto-fast failback option in the Takeover dialog box.

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 london using fast failback

1. From the RDS or RVG view on any host in the RDS choose Change Role > Replay Failback Log.
2. In the Replay Failback Log dialog box, select one of the following options:

   Cache Size	Select Cache Size and specify a default size for the cache object. The default is Megabytes. Select another unit from the drop-down menu, if necessary.
   Cache Name	Select Cache Name and specify the name for a pre-created cache object.
   None	If not using a cache.

3. Click OK. You can check the status of the synchronization using the RDS Summary view.

   The Replay Failback Log wizard 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 dialog box when taking over from the original Primary.

   When the synchronization completes, go to the next step.

4. At a convenient time, stop the application on the new Primary london.
5. Migrate the Primary role from the new Primary host london to the original Primary host seattle using the Migration task (Change Role > 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 Difference-Based Synchronization

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

1. Convert the original Primary to a Secondary using the Make Secondary task (Change Role > 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 difference-based synchronization and checkpoint option of the the Synchronize RVG task (Tools > Synchronize RVG). For detailed instructions, see Synchronize the Secondary RVG with the Primary RVG.
3. Start replication to the new Secondary with the checkpoint by completing the Start Replication task (Replication > Start). For detailed instructions, Synchronizing the Secondary and Starting Replication.
4. Stop the application on the new Primary london.
5. Migrate the Primary role from the new Primary host london to the original Primary host seattle. Replication from the original Primary seattle to the original Secondary london is started by default. See Migrating the Primary Role.

Converting a Primary to a Secondary

Use Change Role > Make Secondary 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

Perform the following steps to convert an original Primary to a Secondary after one of the existing Secondary hosts has become the new Primary:

1. Select the RDS or RVG view on the Primary host, which is the original Primary that failed and is now restarted.
2. From the RDS or RVG view on the Primary host, choose Change Role > Make Secondary.
3. Complete the Make Secondary page as follows:

   New Primary

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

4. Click OK to convert the original Primary to a Secondary. A message displays to indicate whether the takeover succeeded or failed.
5. Click Close.

Synchronize the Secondary RVG with the Primary RVG

Use Tools > Synchronize RVG to synchronize the data volumes on the Secondary with the data volumes on the Primary. The Synchronize RVG task is used in the failback procedure to synchronize the data volumes on the original Primary with the data volumes on the new Primary using difference-based synchronization and checkpoint.

  To synchronize the Secondary RVG with the Primary RVG

Perform the following steps to synchronize the data volumes on the Secondary with the data volumes on the Primary:

1. From the RDS or RVG view, choose Tools > Synchronize RVG.
2. Complete the Synchronize RVG dialog box as follows:

   Option: Difference-based synchronization of RVG Full synchronization of RVG	Click the required synchronization option.
   Checkpoint Name	Enter a name for the checkpoint.
   Secondary Host	From the list, select the name of the Secondary host to synchronize.

3. Click OK to synchronize the data volumes on the Secondary with the data volumes on the Primary. VRW displays the status of the synchronization in a message box. A message displays when the synchronization completes.

Example: Failing Back Using Difference-Based Synchronization

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

  To fail back using difference-based synchronization

1. From the RDS or RVG view, choose Change Role > Make Secondary, and complete the Make Secondary page. Note: In the New Primary field, select or enter london. 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.

2. From the RDS or RVG view, choose Tools > Synchronize RVG, and complete the Synchronize RVG dialog box. Note: In the Synchronize RVG dialog box, select Difference-based synchronization, type the checkpoint name, and select seattle in the Secondary Host field. 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 the difference-based synchronization and checkpoint.

3. Start replication to the Secondary RVG (original Primary) hr_rvg on seattle from the new Primary RVG hr_rvg on london using Replication > Start.
4. In the Start Replication page, select the checkpoint option, and select the checkpoint checkpt_presync from the checkpoint field list.
5. Stop the applications on the new Primary london.
6. Migrate the Primary role from the new Primary host london to the original Primary host seattle using Change Role > 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.