Forcing a Takeover on a System That Uses Sun ZFS Storage Appliance Remote Replication

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 Sun ZFS Storage appliance and the secondary appliance. The information in this section assumes that the protection group has been started.

The following steps occur after you initiate a takeover:

• 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.

• Projects that are replicated in the appliance replication configurations, which are present in the protection group that is being taken over from the former primary cluster cluster-paris, are taken over by the new primary cluster.

  ---

  Note - This data might not be consistent with the original replicas. Data replication from the new primary cluster to the former primary cluster is stopped.

  ---

• Application services are brought online on the new primary cluster.

• The protection group is activated without replication enabled.

For more details about takeover and the effects of the geopg takeover command, see Appendix C, Disaster Recovery Administration Example, in Oracle Solaris Cluster Geographic Edition System Administration Guide.

For details about the possible conditions of the primary and secondary cluster before and after a takeover, see Appendix D, Takeover Postconditions, in Oracle Solaris Cluster Geographic Edition System Administration Guide.

How to Force Immediate Takeover of Sun ZFS Storage Appliance 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:

• The Geographic Edition software is up and running on the secondary cluster.

• The secondary cluster is a member of a partnership.

• The Configuration status of the protection group is OK on the secondary cluster.

Perform this procedure from a node in the secondary cluster.

1. Assume the root role or assume a role that is assigned the Geo Management RBAC rights profile.

   For more information about RBAC, see Geographic Edition Software and RBAC in Oracle Solaris Cluster Geographic Edition System Administration Guide.

   ---

   Note - If you use a role with Geo Management RBAC rights, ensure that the /var/cluster/geo ACLs are correct on each node of both partner clusters. If necessary, assume the root role on the cluster node and set the correct ACLs.

   # chmod A+user:username:rwx:allow /var/cluster/geo

   The /var/cluster/geo directory must have the correct access control lists (ACL) applied for compatibility between the Geo Management RBAC rights profile and Sun ZFS Storage Appliance software.

   ---

2. Initiate the takeover.

   phys-newyork-1# geopg takeover [-f] pg-name

   -f

   Forces the command to perform the operation without your confirmation.

   pg-name

   Specifies the name of the protection group.

Example 2-2 Forcing a Takeover by a Secondary Cluster

The following example forces the takeover of the protection group zfssa-pg by the secondary cluster cluster-newyork.

The node phys-newyork-1 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 zfssa-pg

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.