Forcing a Takeover on a System That Uses Hitachi TrueCopy Data Replication

You perform a takeover when applications need to be brought online on the secondary cluster regardless of whether the data is completely consistent between the primary volume and the secondary volume. The following steps occur after takeover is initiated:

If the former primary cluster, cluster-paris, can be reached, the application services are taken offline on the former primary cluster.

For a reminder of which cluster is cluster-paris, see Figure 2–1.
Data volumes of the former primary cluster, cluster-paris, are taken over by the new primary cluster, cluster-newyork.

Note –
This data might not be consistent with the original primary volumes. After the takeover, data replication from the new primary cluster, cluster-newyork, to the former primary cluster, cluster-paris, is stopped.
Application services are brought online on the new primary cluster, cluster-newyork.

For details about the possible conditions of the primary and secondary cluster before and after takeover, see Appendix C, Takeover Postconditions.

This following sections describe the steps you must perform to force takeover by a secondary cluster.

Validations That Occur Before a Takeover

When a takeover is initiated by using the geopg takeover command, the data replication subsystem runs several validations on both clusters. These step are conducted on the original primary cluster only if the primary cluster can be reached. If validation on the original primary cluster fails, the takeover still occurs.

First, the replication subsystem checks that the Hitachi TrueCopy device group is in a valid aggregate device group state. Then, the replication subsystem checks that the local device group states on the target primary cluster, cluster-newyork, are not 32 or 52. These values correspond to a SVOL_COPY state, for which the horctakeover command will fail. The Hitachi TrueCopy commands used for the takeover are described in the following table.

Table 11–2 Hitachi TrueCopy Takeover Validations on the New Primary Cluster


Aggregate Device Group State	Valid Local State Device Group State	Hitachi TrueCopy Takeover Command Issued on `cluster-newyork`
SMPL	All	No command is issued.
Regular primary	All	No command is issued.
Regular secondary	All Regular secondary states except 32 or 52 For a list of Regular secondary states, refer to Table 10–1 and Table 10–2.	`horctakeover -S -g dg [-t]` The`-t` option is given when the `fence_level` of the Hitachi TrueCopy device group is `async`. The value is calculated as 80% of the protection group's `Timeout` property. For example, if the protection group has a `Timeout` of 200 seconds, the value of `-t` used in this command will be 80% off 200 seconds, or 160 seconds.
Takeover primary	All	No command is issued.
Takeover secondary	All	`pairsplit -R-g dgpairsplit -S-g dg`

Results of a Takeover From a Replication Perspective

From a replication perspective, after a successful takeover, the Local-role property of the protection group is changed to reflect the new role, regardless of whether the application could be brought online on the new primary cluster as part of the takeover operation. On cluster-newyork, where the protection group had a Local-role of Secondary, the protection group's Local-role becomes Primary. On cluster-paris, where the protection group had a Local-role of Primary, the following may occur:

If the cluster can be reached, the protection group's Local-role becomes Secondary.
If the cluster cannot be reached, the protection group's Local-role remains Primary.

If the takeover is successful, the applications are brought online. You do not need to issue a separate geopg start command

Caution –

After a successful takeover, data replication between the new primary cluster, cluster-newyork, and the old primary cluster, cluster-paris is stopped. If you want to issue a geopg start command, you must use the -n option to prevent replication from resuming.

How to Force Immediate Takeover of Hitachi TrueCopy Services by a Secondary Cluster

Before You Begin

Before you force the secondary cluster to assume the activity of the primary cluster, ensure that the following conditions are met:

Sun Cluster Geographic Edition software is up and running on the cluster.
The cluster is a member of a partnership.
The Configuration status of the protection group is OK on the secondary cluster.

Steps

Log in a node in the secondary cluster.

You must be assigned the Geo Management RBAC rights profile to complete this procedure. For more information about RBAC, see Sun Cluster Geographic Edition Software and RBAC.

Initiate the takeover.
# geopg takeover [-f] protection-group-name
-f

Forces the command to perform the operation without your confirmation

protection-group-name

Specifies the name of the protection group

Example 11–2 Forcing a Takeover by a Secondary Cluster

The following example illustrates forcing the takeover of tcpg by the secondary cluster cluster-newyork.

phys-newyork-1 is the first node of the secondary cluster. For a reminder of which node is phys-newyork-1, see Example Sun Cluster Geographic Edition Cluster Configuration.

phys-newyork-1# geopg takeover -f tcpg