Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Cluster Geographic Edition Data Replication Guide for Oracle Solaris Availability Suite Oracle Solaris Cluster 4.0 |
1. Replicating Data With the Availability Suite Feature of Oracle Solaris
2. Administering Availability Suite Protection Groups
3. Migrating Services That Use Availability Suite Data Replication
Detecting Cluster Failure on a System That Uses Availability Suite Data Replication
Detecting Primary Cluster Failure
Detecting Secondary Cluster Failure
Migrating Services That Use Availability Suite With a Switchover
How to Switch Over an Availability Suite Protection Group From Primary to Secondary
Actions Performed by the Geographic Edition Software During a Switchover
Forcing a Takeover on Systems That Use Availability Suite
How to Force Immediate Takeover of Availability Suite Services by a Secondary Cluster
Actions Performed by the Geographic Edition Software During a Takeover
Recovering Availability Suite Data After a Takeover
How to Resynchronize and Revalidate the Protection Group Configuration
How to Perform a Failback-Switchover on a System That Uses Availability Suite Replication
How to Perform a Failback-Takeover on a System That Uses Availability Suite Replication
Recovering From an Availability Suite Data Replication Error
How to Recover From a Data Replication Error
You perform a switchover of an Availability Suite protection group when you want to migrate services to the partner cluster in an orderly fashion. A switchover consists of the following:
Application services are unmanaged on the former primary cluster, cluster-paris.
For a reminder of which cluster is cluster-paris, see Example Geographic Edition Cluster Configuration in Oracle Solaris Cluster Geographic Edition System Administration Guide.
The data replication role is reversed and now continues to run from the new primary, cluster-newyork, to the former primary, cluster-paris.
Application services are brought online on the new primary cluster, cluster-newyork.
This section provides the following information:
How to Switch Over an Availability Suite Protection Group From Primary to Secondary
Actions Performed by the Geographic Edition Software During a Switchover
Before You Begin
For a switchover to occur, data replication must be active between the primary cluster and the secondary cluster. Additionally, the data volumes on the two clusters must be in a synchronized state.
Before you switch over a protection group from the primary cluster to the secondary cluster, ensure that the following conditions are met:
Geographic Edition software is running on the both clusters.
The secondary cluster is a member of a partnership.
Both cluster partners can be reached.
The overall state of the protection group is OK.
You must be assigned the Geo Management RBAC rights profile to complete this procedure. For more information about RBAC, see Geographic Edition Software and RBAC in Oracle Solaris Cluster Geographic Edition System Administration Guide.
The application resource groups that are a part of the protection group are stopped and started during the switchover.
# geopg switchover [-f] -m newprimarycluster protectiongroupname
Forces the command to perform the operation without asking you for confirmation
Specifies the name of the cluster that is to be the primary cluster for the protection group
Specifies the name of the protection group
Example 3-1 Forcing a Switchover From Primary to Secondary
This example performs a switchover to the secondary cluster.
# geopg switchover -f -m cluster-newyork avspg
When you run the geopg switchover command, the software confirms that the volume sets that are associated with the device groups are in the replicating state. Then, the software performs the following actions on the original primary cluster:
Removes affinities and resource dependencies between all the application resource groups in the protection group and the internal resource group, such as the lightweight resource groups
Takes the application resource groups offline and places them in the Unmanaged state
Waits for writes to complete
Unmounts the primary volumes that correspond to the device groups in the protection group
Stops data replication by placing all volume sets in logging mode
Reverses the role of all volume sets
On the original secondary cluster, the command takes the following actions:
Places all volume sets in logging mode
Reverses the role of all volume sets
Starts data replication by issuing update synchronization with the autosynchronization feature active
Runs the script that is defined in the RoleChange_ActionCmd property
Brings all application resource groups online and adds the affinities between the application resource groups and the internal resource groups, such as the lightweight resource group
If the command completes successfully, the secondary cluster, cluster-newyork, becomes the new primary cluster for the protection group. The original primary cluster, cluster-paris, becomes the new secondary cluster. Volume sets associated with a device group of the protection group have their role reversed according to the role of the protection group on the local cluster. The application resource group is online on the new primary cluster. Data replication from the new primary cluster to the new secondary cluster begins.
This command returns an error if any of the previous operations fails. Run the geoadm status command to view the status of each component. For example, the Configuration status of the protection group might be set to Error, depending on the cause of the failure. The protection group might be activated or deactivated.
If the Configuration status of the protection group is set to Error, revalidate the protection group by using the procedures described in How to Validate an Availability Suite Protection Group.
If the configuration of the protection group is not the same on each partner cluster, you need to resynchronize the configuration by using the procedures described in How to Resynchronize an Availability Suite Protection Group.