After a successful takeover operation, the secondary cluster (cluster-newyork) becomes the primary for the protection group and the services are online on the secondary cluster. After the recovery of the original primary cluster, the services can be brought online again on the original primary by using a process called failback.
Sun Cluster Geographic Edition software supports the following two kinds of failback:
Failback-switchover. During a failback-switchover, applications are brought online again on the original primary cluster, cluster-paris, after the primary cluster's data was resynchronized with the data on the secondary cluster, cluster-newyork.
For a reminder of which clusters are cluster-paris and cluster-newyork, see Figure 2–1.
Failback-takeover. During a failback-takeover, applications are brought online again on the original primary cluster and use the current data on the primary cluster. Any updates that occurred on the secondary cluster are discarded.
Use this procedure to restart an application on the original primary cluster, cluster-paris, after this cluster's data has been resynchronized with the data on the current primary cluster, cluster-newyork.
Before you perform a failback-switchover, a takeover has occurred on cluster-newyork. The clusters now have the following roles:
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 the protection group could be reached during the takeover.
Resynchronize the original primary cluster, cluster-paris, with the current primary cluster, cluster-newyork.
cluster-paris forfeits its own configuration and replicates the cluster-newyork configuration locally. Resynchronize both the partnership and protection group configurations.
On cluster-paris, deactivate the protection group on the local cluster.
# geopg stop -e Local protection-group-name |
Specifies the scope of the command
By specifying a local scope, the command operates on the local cluster only.
Specifies the name of the protection group
If the protection group is already deactivated, the state of the resource group in the protection group is probably Error. The state is Error because the application resource groups are managed and offline.
Deactivating the protection group will result in the application resource groups no longer being managed, clearing the Error state.
On cluster-paris, resynchronize the partnership.
# geops update partnership-name |
Specifies the name of the partnership
You need to perform this step only once, even if you are performing a failback-switchover for multiple protection groups.
For more information about synchronizing partnerships, see Resynchronizing a Partnership.
On cluster-paris, resynchronize each protection group.
Because the role of the protection group on cluster-newyork is primary, this step ensures that the role of the protection group on cluster-paris is secondary.
# geopg update protection-group-name |
Specifies the name of the protection group
For more information about synchronizing protection groups, see Resynchronizing a Sun StorEdge Availability Suite 3.2.1 Protection Group.
On cluster-paris, validate the cluster's configuration for each protection group.
# geopg validate protection-group-name |
Specifies a unique name that identifies a single protection group
For more information, see How to Validate a Sun StorEdge Availability Suite 3.2.1 Protection Group.
On cluster-paris, activate each protection group.
When you activate a protection group, its application resource groups are also brought online.
# geopg start -e Global protection-group-name |
Specifies the scope of the command
By specifying a Global scope, the command operates on both clusters where the protection group is deployed.
Specifies the name of the protection group
The -n option must not be given when doing a failback-switchover because the data needs to be synchronized from the current primary, cluster-newyork, to the current secondary, cluster-paris.
Because the protection group has a role of secondary, the data is synchronized from the current primary, cluster-newyork, to the current secondary, cluster-paris.
For more information about the geopg start command, see How to Activate a Sun StorEdge Availability Suite 3.2.1 Protection Group.
Confirm that the data is completely synchronized.
First, confirm that the state of the protection group on cluster-newyork is OK.
phys-newyork-1# geoadm status |
Refer to the Protection Group section of the output.
Next, confirm that all resources in the replication resource group, AVS-protection-group-name-rep-rg, report a status of OK.
phys-newyork-1# scstat -g |
On either cluster, perform a switchover from cluster-newyork to cluster-paris for each protection group.
# geopg switchover [-f] -m cluster-paris protection-group-name |
For more information, see How to Switch Over a Sun StorEdge Availability Suite 3.2.1 Protection Group From Primary to Secondary.
cluster-paris resumes its original role as primary cluster for the protection group.
Ensure that the switchover was performed successfully by using the geoadm status on either cluster to verify that the replication resource and the application resource groups and resources are online.
Also, you must verify that the protection group is now primary on cluster-paris and secondary on cluster-newyork and that “Data replication” and “Resource groups” are listed in OK states for both clusters.
# geoadm status |
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.
Conditionally, you can 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.
Before you begin the failover-takeover operation, the clusters have the following roles:
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 the protection group could be reached during the takeover.
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.
On cluster-paris, resynchronize the partnership.
# geops update partnership-name |
Specifies the name of the partnership
You need to perform this step only once, even if you are performing a failback-takeover for multiple protection groups.
For more information about synchronizing partnerships, see Resynchronizing a Partnership.
On cluster-paris, resynchronize each protection group.
If the protection group has been activated, deactivate the protection group by using the geopg stop command. For more information about deactivating a protection group, see How to Deactivate a Sun StorEdge Availability Suite 3.2.1 Protection Group.
# geopg update protection-group-name |
Specifies the name of the protection group
For more information about synchronizing protection groups, see How to Resynchronize a Sun StorEdge Availability Suite 3.2.1 Protection Group.
On cluster-paris, validate the cluster's configuration for each protection group.
# geopg validate protection-group-name |
Specifies a unique name that identifies a single protection group
For more information, see How to Validate a Sun StorEdge Availability Suite 3.2.1 Protection Group.
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.
# geopg start -e local -n protection-group-name |
Specifies the scope of the command
By specifying a local scope, the command operates on the local cluster only.
Prevents the start of data replication at protection group startup
You must use the -n option.
Specifies the name of the protection group
For more information, see How to Activate a Sun StorEdge Availability Suite 3.2.1 Protection Group.
Replication from cluster-newyork to cluster-paris is not started, because the -n option is given on cluster-paris.
On cluster-paris, initiate a takeover for each protection group.
# geopg takeover [-f] protection-group-name |
Forces the command to perform the operation without your confirmation
Specifies the name of the protection group
For more information about the geopg takeover command, see How to Force Immediate Takeover of Sun StorEdge Availability Suite 3.2.1 Services by a Secondary Cluster.
The protection group on cluster-paris now has the primary role, and the protection group on cluster-newyork has the secondary role.
On cluster-newyork, activate each protection group.
Because the protection group on cluster-newyork has a role of secondary, the geopg start command does not restart the application on cluster-newyork.
# geopg start -e local [-n] protection-group-name |
Specifies the scope of the command
By specifying a local scope, the command operates on the local cluster only.
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.
Specifies the name of the protection group
For more information about the geopg start command, see How to Activate a Sun StorEdge Availability Suite 3.2.1 Protection Group.
Start data replication.
To start data replication, activate the protection group on the primary cluster, cluster-paris.
# geopg start -e local protection-group-name |
For more information about the geopg start command, see How to Activate a Sun StorEdge Availability Suite 3.2.1 Protection Group.