A takeover consists of the following actions:
If the former primary cluster can be reached and the protection group is not locked for notification handling or some other reason, the protection group is deactivated.
The data of the former primary cluster is taken over by the new primary cluster.
Application services are brought online on the new primary cluster.
The protection group is activated without replication enabled.
For Hitachi TrueCopy or Universal Replicator, 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.
|
For more details about takeover and the effects of the geopg takeover command, see Appendix B, Disaster Recovery Administration Example, in Oracle Solaris Cluster 4.3 Geographic Edition System Administration Guide.
For details about the possible conditions of the primary and secondary cluster before and after a takeover, see Appendix C, Post-Takeover Conditions, in Oracle Solaris Cluster 4.3 Geographic Edition System Administration Guide.