How to Perform a Failback-Takeover on a System That Uses Oracle Solaris ZFS Snapshot Replication

Language:

Use this procedure to restart an application on the original primary cluster and use the current data on the original primary cluster. Any updates that occurred on the secondary cluster while it was acting as primary are discarded.

The failback procedures apply only to clusters in a partnership.

Note - To resume using the data on the original primary you must not have replicated data from the current primary to the original primary cluster at any point after the takeover operation on the current primary cluster. To prevent replication between the current primary and the original primary, you must have used the –n option whenever you used the geopg start command.

Before You Begin

Ensure that the following conditions are met:

If the original primary cluster was down, the cluster is booted and the disaster recovery framework infrastructure is enabled on the cluster. For more information about booting a cluster, see Booting a Cluster in Administering the Disaster Recovery Framework for Oracle Solaris Cluster 4.4.
The protection group on the current primary cluster has the primary role.
The protection group on the original primary cluster has either the primary role or secondary role depending on whether the original primary can be reached during the takeover from the current primary.

This procedure uses the example names paris for the original primary cluster and newyork for the current primary cluster.

On the current primary cluster, newyork, stop the protection group locally.
```
newyork-node-1# geopg stop -e local protection-group
```
–e local

Specifies the scope of the command. The local scope applies the command on the local cluster only.

protection-group

Specifies the name of the protection group.
Make the protection group primary on paris and secondary on newyork.
- If paris has the secondary role, run the following command from paris:
```
paris-node-1# geopg takeover protection-group
```
- If paris has the primary role, run the following command from newyork:
```
newyork-node-1# geopg update protection-group
```
Validate the configuration of the protection group on each cluster.
Ensure that the protection group is not in an error state. A protection group cannot be started when it is in a error state.
```
paris-node-1# geopg validate protection-group
newyork-node-1# geopg validate protection-group
```
For more information, see Validating a Protection Group in Installing and Configuring the Disaster Recovery Framework for Oracle Solaris Cluster 4.4.

From either cluster, start the protection group globally.
```
paris-node-1# geopg start -e global protection-group
```
The protection group on paris now has the primary role, and the protection group on newyork has the role of secondary. The application services are now online on paris.

For more information, see How to Activate a Protection Group in Administering the Disaster Recovery Framework for Oracle Solaris Cluster 4.4.
Ensure that the protection group was started successfully as primary on cluster paris and as secondary on cluster newyork.
Verify that the protection group is now primary on paris and secondary on newyork and that the state for "Data replication" and "Resource groups" is OK on both clusters.
```
# geoadm status
```
Check the runtime status of the application resource group and replication status resource group for the protection group, and the status for each replication status resource associated with a replication component in the protection group.
```
# clresourcegroup status application-rg-in-pg 
# clresource status -g application-rg-in-pg
# clresourcegroup status replication-status-rg-for-pg 
# clresource status -g replication-status-rg-for-pg
```
Refer to the Status and Status Message fields for the replication status resource of each replication component you want to check.

For more information about the runtime status of replication, see Checking the Runtime Status of Oracle Solaris ZFS Snapshot Remote Replication.