How to Perform a Failback-Takeover on a System That Uses Oracle ZFS Storage Appliance 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. Perform the following procedure only once per partnership.

Note - To resume using the data on the original primary you must not have replicated data from the new primary to the original primary cluster, cluster-paris, 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 clusters have the following roles:

If the original primary cluster had been down, the cluster is booted and the disaster recovery framework 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 cluster-paris for the original primary cluster and cluster-newyork for the current primary cluster.

Log in to the Oracle ZFS Storage appliance on the cluster-paris site.
On the paris appliance, remove the replication action for the project.
On the paris appliance, re-add the replication action and enable it with continuous mode.
The package is created on the original primary appliance, paris. The corresponding package is created on the original secondary appliance, newyork.
On the original secondary cluster, cluster-newyork, stop the protection group locally.
```
phys-newyork-1# geopg stop -e local protection-group
```
–e local

Specifies the scope of the command. By specifying a local scope, the command operates on the local cluster only.

protection-group

Specifies the name of the protection group.

Note - Wait for the replica package to appear on cluster-newyork before you continue to the next step.
Make the protection group primary on cluster-paris and secondary on cluster-newyork.
- If cluster-paris has the secondary role, run the following command from cluster-paris:
```
phys-paris-1# geopg takeover protection-group
```
- If cluster-paris has the primary role, run the following command from cluster-newyork:
```
phys-newyork-1# geopg update protection-group
```
On cluster-paris, validate the configuration for each protection group.
Ensure that the protection group is not in an error state. A protection group cannot be started when it is in a error state.
```
phys-paris-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.
```
phys-paris-1# geopg start -e global protection-group
```
The protection group on cluster-paris now has the primary role, and the protection group on cluster-newyork has the role of secondary. The application services are now online on cluster-paris.

For more information, see How to Activate a Protection Group in Administering the Disaster Recovery Framework for Oracle Solaris Cluster 4.4.
Remove obsolete projects from the newyork appliance.
1. Ensure that the protection group is activated and that all components are in the OK state on both clusters.
```
# geoadm status
```
2. Access the BUI on the newyork appliance.
3. Navigate to Shares > Projects.
4. If any projects in the protection group are listed, manually delete them.