Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Cluster Geographic Edition Data Replication Guide for Hitachi TrueCopy and Universal Replicator |
1. Replicating Data With Hitachi TrueCopy and Universal Replicator Software
2. Administering Hitachi TrueCopy and Universal Replicator Protection Groups
3. Migrating Services That Use Hitachi TrueCopy and Universal Replicator Data Replication
Detecting Primary Cluster Failure
Detecting Secondary Cluster Failure
Validations That Occur Before a Switchover
Results of a Switchover From a Replication Perspective
Forcing a Takeover on a System That Uses Hitachi TrueCopy or Universal Replicator Data Replication
Validations That Occur Before a Takeover
How to Resynchronize and Revalidate the Protection Group Configuration
Recovering From Switchover Failure
Recovering From a Hitachi TrueCopy or Universal Replicator Data Replication Error
How to Detect Data Replication Errors
How to Recover From a Hitachi TrueCopy or Universal Replicator Data Replication Error
A. Geographic Edition Properties for Hitachi TrueCopy and Universal Replicator
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 information in this section assumes that the protection group has been started.
The following steps occur after a takeover is initiated:
If the former primary cluster, cluster-paris, can be reached and the protection group is not locked for notification handling or some other reason, the application services are taken offline on the former primary cluster.
For a reminder of which cluster is cluster-paris, see Example Geographic Edition Cluster Configuration in Oracle Solaris Cluster Geographic Edition System Administration Guide.
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 D, Takeover Postconditions, in Oracle Solaris Cluster Geographic Edition System Administration Guide.
The following sections describe the steps you must perform to force a takeover by a secondary cluster.
When a takeover is initiated by using the geopg takeover command, the data replication subsystem runs several validations on both clusters. These steps 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 or Universal Replicator 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 fails. The Hitachi TrueCopy or Universal Replicator commands that are used for the takeover are described in the following table.
Table 3-2 Hitachi TrueCopy or Universal Replicator Takeover Validations on the New Primary Cluster
|
From a replication perspective, after a successful takeover, the Local-role property of the protection group is changed to reflect the new role, it is immaterial 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 Local-role property of the protection group becomes Primary. On cluster-paris, where the protection group had a Local-role of Primary, the following might occur:
If the cluster can be reached, the Local-role property of the protection group becomes Secondary.
If the cluster cannot be reached, the Local-role property of the protection group remains Primary.
If the takeover is successful, the applications are brought online. You do not need to run 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 run a geopg start command, you must use the -n option to prevent replication from resuming. |
Before You Begin
Before you force the secondary cluster to assume the activity of the primary cluster, ensure that the following conditions are met:
Geographic Edition software is 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.
You must be assigned the Geo Management RBAC rights profile to complete this procedure. For more information about RBAC, see Geographic Edition Software and RBAC in Oracle Solaris Cluster Geographic Edition System Administration Guide.
# geopg takeover [-f] protectiongroupname
Forces the command to perform the operation without your confirmation
Specifies the name of the protection group
Example 3-2 Forcing a Takeover by a Secondary Cluster
This example forces the takeover of tcpg by the secondary cluster cluster-newyork.
The phys-newyork-1 cluster is the first node of the secondary cluster. For a reminder of which node is phys-newyork-1, see Example Geographic Edition Cluster Configuration in Oracle Solaris Cluster Geographic Edition System Administration Guide.
phys-newyork-1# geopg takeover -f tcpg
Next Steps
For information about the state of the primary and secondary clusters after a takeover, see Appendix D, Takeover Postconditions, in Oracle Solaris Cluster Geographic Edition System Administration Guide.