You perform a takeover when applications need to be brought online on the standby cluster, regardless of whether the data is completely consistent between the primary database and the standby database. In this section, it is assumed that the protection group has been started.
The following operations occur after you initiate a takeover:
If the former primary cluster, cluster-paris, can be reached and the protection group is not locked for notification handling or some other reason, the protection group is deactivated.
For a reminder of which cluster is cluster-paris, see Example Sun Cluster Geographic Edition Cluster Configuration in Sun Cluster Geographic Edition System Administration Guide.
Databases replicated in the Oracle Data Guard Broker configurations, which are present in the protection group that is being taken over from the former primary cluster cluster-paris, are taken over by the new primary cluster cluster-newyork.
This data might not be consistent with the original databases. Data replication from the new primary cluster, cluster-newyork, to the former primary cluster, cluster-paris, is stopped.
The protection group is activated without data replication enabled. The former primary databases in each of the Oracle Data Guard Broker configurations that are taken over are placed in a disabled, recovery required, state.
For details about the possible conditions of the primary and standby clusters before and after a takeover, see Appendix C, Takeover Postconditions, in Sun Cluster Geographic Edition System Administration Guide.
This section provides the following information:
How to Force Immediate Takeover of Oracle Data Guard Services by a Standby Cluster
Actions Performed by the Sun Cluster Geographic Edition Software During a Takeover
Before you force the standby cluster to assume the activity of the primary cluster, ensure that the following conditions are met:
Sun Cluster Geographic Edition software is up and running on the cluster.
The cluster is a member of a partnership.
The Configuration status of the protection group is set to OK on the standby cluster.
Log in to a node in the standby cluster.
To complete this step, you need to be assigned the Geo Management RBAC rights profile. For more information about RBAC, see Sun Cluster Geographic Edition Software and RBAC in Sun Cluster Geographic Edition System Administration Guide.
Initiate the takeover.
phys-node-n# geopg takeover [-f] protectiongroupname |
Forces the command to perform the operation without your confirmation.
Specifies the name of the protection group.
This example shows how to force the takeover of sales-pg by the standby cluster cluster-newyork.
The node phys-newyork-1 is the first node of the standby cluster. For a reminder of which node is phys-newyork-1, see Example Sun Cluster Geographic Edition Cluster Configuration in Sun Cluster Geographic Edition System Administration Guide.
phys-newyork-1# geopg takeover -f sales-pg |
For information about the state of the primary and the standby clusters after a takeover, see Appendix C, Takeover Postconditions, in Sun Cluster Geographic Edition System Administration Guide.
When you run the geopg takeover command, the software confirms that databases in the Oracle Data Guard Broker configuration on the standby cluster, that is, the future primary, are enabled (as you cannot perform a takeover to a disabled database). The software also confirms that the Oracle Data Guard command-line interface show configuration command either shows a SUCCESS state or is busy performing a health check (ORA-16610). If the show configuration command returns any other Oracle error code, the takeover fails.
If the original primary cluster, cluster-paris, can be reached, the software takes the application resource groups offline and places them in an Unmanaged state.
On the original standby cluster, cluster-newyork, the software performs the following operations:
Runs the Oracle Data Guard command line interface failover to standby-database-name immediate command
Runs the script that is specified by the RoleChange_ActionCmd property
If the protection group was active on the original standby cluster before the takeover, brings all Oracle shadow RAC server proxy resource groups and application resource groups online
If the command completes successfully, the standby cluster, cluster-newyork, becomes the new primary cluster for the protection group. Databases that are associated with the Oracle Data Guard Broker configurations of the protection group have their role reversed according to the role of the protection group on the local cluster. The Oracle shadow RAC server proxy resource group and any other application resource group are online on the new primary cluster. If the original primary cluster can be reached, it becomes the new standby cluster of the protection group. Replication of all databases that are associated with the Oracle Data Guard Broker configurations of the protection group are stopped.
After a successful takeover, data replication is stopped. If you want to continue to suspend replication, specify the -n option when you use the geopg start command. This option prevents the start of data replication from the new primary cluster to the new standby cluster.
If a previous operation fails, this command returns an error. Use the geoadm status command to view the status of each component. For example, the Configuration status of the protection group might be set to an Error state, 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 the Error state, revalidate the protection group by using the procedures that are described in How to Validate an Oracle Data Guard 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 Oracle Data Guard Protection Group.