Taking Over from an Original Primary

The takeover procedure involves transferring the Primary role from an original Primary to a Secondary. When the original Primary fails or is destroyed because of a disaster, the takeover procedure enables you to convert a consistent Secondary to a Primary. The takeover of a Primary role by a Secondary is useful when the Primary experiences unscheduled downtimes or is destroyed because of a disaster.

Use the Takeover task to transfer the Primary role from an original Primary to a Secondary. The Takeover task must be performed on the Secondary host. The Takeover task fails when performed on a Primary host.

The Takeover task performs the following functions on the RDS to which the original Primary belongs:

• Converts the Secondary RVG to a Primary RVG.
• Removes the original Primary from the RDS.
• Enables the fast-failback feature on the new Primary depending on the failback option that you select from the Takeover task. For information on failing back, see Failing Back to the Original Primary.

For details on taking over from the original Primary, refer to Transferring the Primary Role.

Failback Options

The Takeover task provides the following options to fail back to the original Primary. Select the required option depending on the method you plan to use for failback.

• Fast Failback---This is the default and is the recommended option. This option enables fast failback. Use this option if you want to incrementally synchronize the original Primary with the new Primary. However, conversion of the original Primary to a Secondary and synchronization of the original Primary data volumes with the data volumes on the new Primary is not done automatically.

To synchronize the data volumes on the original Primary and convert the original Primary to a Secondary, use the Replay Failback Log task (Replication > Replay Failback Log) on the RDS.

• Auto fast failback---Use this option if you want to convert the original Primary to a Secondary after the original Primary becomes available and also to automatically synchronize the data volumes on original Primary, which is now the new Secondary, using fast failback.
• No fast failback ---If you choose this option, you must synchronize the original Primary after it becomes available. Use this option 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.

---

 Tip    We recommend that you use the Fast failback option to synchronize the original Primary with the new Primary. For instructions, see Failing Back Using Fast-Failback Synchronization.

---

  To take over from the original Primary to the Secondary

1. Make sure you have logged on to the Secondary host. To log on to a host from VVR VEA, choose File > Connect and specify the name of the Secondary host to which you want to connect.
2. From the tree view, select the name of Secondary host whose role you want to change to Primary. For example, london.
3. Choose Replication > Takeover. To use the pop-up menu, right-click the name of the RDS and select Takeover.

   

   Click the thumbnail above to view full-sized image.

4. Complete the Takeover dialog box as follows:

   Options: Fast Failback Auto fast failback No fast failback

   By default, Fast failback is selected. If this option is not appropriate, select the required option. To enable fast failback logging only, select Fast failback. You can synchronize the data volumes on the original Primary and convert the original Primary to a Secondary using the Replay Failback Log task (Replication > Replay Failback Log). To convert the original Primary to a Secondary after it becomes available, and also automatically use the DCM to synchronize the data volumes on the original Primary using fast failback, select Auto fast failback. To change the role from Secondary to Primary without enabling fast failback, select No fast failback. Select this option 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.

5. Click OK. A message that indicates whether the takeover succeeded or failed is displayed.
6. Start the application on the new Primary. Starting the applications on the new Primary after a takeover may require an application recovery to be run.

   Notes:
   If you want to use the fast-failback feature, make sure that the data volumes on the Secondary host have associated DCMs. If fast failback is enabled, the RDS View displays the value DCM in the Logging To column for the original Primary.