How to Perform a Failback-Takeover on a System That Uses SRDF Replication

Language:

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

The failback procedures apply only to clusters in a partnership. You need to perform the following procedure only once per partnership.

Note - To resume using the data on the original primary, cluster-paris, you must not have replicated data from the new primary, cluster-newyork, to the original primary cluster, cluster-paris, at any point after the takeover operation on cluster-newyork. To prevent data replication between the new 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, cluster-paris, has been down, confirm that the cluster is booted and that the Geographic Edition infrastructure is enabled on the cluster. For more information about booting a cluster, see Booting a Cluster in Oracle Solaris Cluster Geographic Edition System Administration Guide .
The protection group on cluster-newyork has the primary role.
The protection group on cluster-paris has either the primary role or secondary role, depending on whether cluster-paris can be reached during the takeover from cluster-newyork.

Ensure that the RDF1 role is not in the Split state on cluster-paris.
This task is necessary to finish recovery if the cluster had experienced a complete site failure.
1. On cluster-paris, display the role and state of the data replication.
```
phys-paris-1# symrdf -g device-group query
```
2. If the role is RDF1 and is in the Split state, fail over the device group.
```
phys-paris-1# symrdf -g device-group failover
```
Resynchronize the original primary cluster, cluster-paris, with the original secondary cluster, cluster-newyork.
cluster-paris forfeits its own configuration and replicates the cluster-newyork configuration locally.
1. On cluster-paris, resynchronize the partnership.
```
phys-paris-1# geops update partnership
```
  partnership
  
  Specifies the name of the partnership
  
  Note - You need to perform this step only once per partnership, even if you are performing a failback-takeover for multiple protection groups in the partnership.
  
  For more information about synchronizing partnerships, see Resynchronizing a Partnership in Oracle Solaris Cluster Geographic Edition System Administration Guide .
2. Determine whether the protection group on the original primary cluster, cluster-paris, is active.
```
phys-paris-1# geoadm status
```
3. If the protection group on the original primary cluster is active, stop it.
```
phys-paris-1# geopg stop -e local protection-group
```
4. Verify that the protection group is stopped.
```
phys-paris-1# geoadm status
```
5. On cluster-paris, resynchronize each protection group.
  Because the local role of the protection group on cluster-newyork is now primary, this steps ensures that the role of the protection group on cluster-paris becomes secondary.
```
phys-paris-1# geopg update protection-group
```
  protection-group
  
  Specifies the name of the protection group
  
  For more information about resynchronizing protection groups, see Resynchronizing a Protection Group in Oracle Solaris Cluster Geographic Edition System Administration Guide .
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 
```
protection-group

Specifies a unique name that identifies a single protection group

For more information, see Validating a Protection Group in Oracle Solaris Cluster Geographic Edition Installation and Configuration Guide .
On cluster-paris, activate each protection group in the secondary role without data replication.
Because the protection group on cluster-paris has a role of secondary, the geopg start command does not restart the application on cluster-paris.

Note - You must use the –n option which specifies that data replication should not be used for this protection group. If this option is omitted, data replication starts at the same time as the protection group.
```
phys-paris-1# geopg start -e local -n protection-group
```
–e local

Specifies the scope of the command.

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

–n

Specifies that data replication should not be used for this protection group. If this option is omitted, data replication starts at the same time as the protection group.

protection-group

Specifies the name of the protection group

For more information, see How to Activate a Protection Group in Oracle Solaris Cluster Geographic Edition System Administration Guide .

Replication from cluster-newyork to cluster-paris is not started because the –n option is used on cluster-paris.
On cluster-paris, initiate a takeover for each protection group.
```
phys-paris-1# geopg takeover [-f] protection-group
```
–f

Forces the command to perform the operation without your confirmation

protection-group

Specifies the name of the protection group

For more information about the geopg takeover command, see How to Force Immediate Takeover of a Protection Group by a Secondary Cluster in Oracle Solaris Cluster Geographic Edition System Administration Guide .

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.
On cluster-newyork, activate each protection group.
At the end of step 4, the local state of the protection group on cluster-newyork is Offline. To start monitoring the local state of the protection group, you must activate the protection group on cluster-newyork.

Because the protection group on cluster-newyork has a role of secondary, the geopg start command does not restart the application on cluster-newyork.
```
phys-newyork-1# geopg start -e local [-n] protection-group
```
–e local

Specifies the scope of the command.

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

–n

Prevents the start of data replication at protection group startup.

If you omit this option, the data replication subsystem starts at the same time as the protection group.

protection-group

Specifies the name of the protection group.

For more information about the geopg start command, see How to Activate a Protection Group in Oracle Solaris Cluster Geographic Edition System Administration Guide .
Ensure that the takeover was performed successfully.
Verify that the protection group is now primary on cluster-paris and secondary on cluster-newyork and that the state for “Data replication” and “Resource groups” is OK on both clusters.
```
# geoadm status
```
Note - If you used the –n option in step 5 to prevent data replication from starting, the “Data replication” status will not be in the OK state.

Check the runtime status of the application resource group and data replication for each SRDF protection group.
```
# clresourcegroup status -v protection-group
```
Refer to the Status and Status Message fields that are presented for the data replication device group you want to check. For more information about these fields, see Table 2–1.

For more information about the runtime status of data replication, see Checking the Runtime Status of SRDF Data Replication.