Skip Navigation Links | |
Exit Print View | |
![]() |
Oracle Solaris Cluster Geographic Edition Data Replication Guide for Oracle Data Guard |
1. Replicating Data With Oracle Data Guard Software
2. Administering Oracle Data Guard Protection Groups
3. Migrating Services That Use Oracle Data Guard Data Replication
Detecting Cluster Failure on a System That Uses Oracle Data Guard Data Replication
Detecting Primary Cluster Failure
Detecting Failure of the Standby Cluster
Migrating Services That Use Oracle Data Guard With a Switchover
How to Switch Over an Oracle Data Guard Protection Group From the Primary to the Standby Cluster
Actions Performed by the Geographic Edition Software During a Switchover
Forcing a Takeover on Systems That Use Oracle Data Guard
How to Force Immediate Takeover of Oracle Data Guard Services by a Standby Cluster
Actions Performed by the Geographic Edition Software During a Takeover
Recovering Oracle Data Guard Data After a Takeover
How to Resynchronize and Revalidate the Protection Group Configuration
How to Perform a Failback Switchover on a System That Uses Oracle Data Guard Replication
How to Perform a Failback Takeover on a System That Uses Oracle Data Guard Replication
Recovering From an Oracle Data Guard Data Replication Error
How to Recover From a Data Replication Error
A. Geographic Edition Properties for Oracle Data Guard Broker Configurations
After a successful takeover operation, the standby cluster, cluster-newyork, becomes the primary for the protection group, and the services are online on the standby cluster. After the recovery of the original primary cluster, the services can be brought online again on the original primary cluster by using a process called failback.
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 data has been resynchronized with the data on the standby cluster cluster-newyork.
For a reminder of which clusters are cluster-paris and cluster-newyork, see Example Geographic Edition Cluster Configuration in Oracle Solaris Cluster Geographic Edition System Administration Guide.
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 standby cluster are discarded.
If you want to leave the new primary, cluster-newyork, as the primary cluster and the original primary cluster, cluster-paris, as the standby cluster after the original primary cluster starts again , you can resynchronize and revalidate the protection group configuration. You can resynchronize and revalidate the protection group without performing a switchover or takeover.
This section describes how to perform the following procedures:
How to Resynchronize and Revalidate the Protection Group Configuration
How to Perform a Failback Switchover on a System That Uses Oracle Data Guard Replication
How to Perform a Failback Takeover on a System That Uses Oracle Data Guard Replication
Follow this procedure to resynchronize and revalidate data on the original primary cluster, cluster-paris, with the data on the current primary cluster cluster-newyork.
Before You Begin
Before you resynchronize and revalidate the protection group configuration, a takeover has occurred on cluster-newyork. The clusters now have the following roles:
The protection group on cluster-newyork is assigned the primary role.
The protection group on cluster-paris has either the primary role or secondary role, depending on whether cluster-paris could be reached during the takeover from cluster-newyork.
For more information about booting a cluster, see Booting a Cluster in Oracle Solaris Cluster Geographic Edition System Administration Guide.
The cluster cluster-paris forfeits its own configuration and replicates the cluster-newyork configuration locally. Resynchronize both the partnership and protection group configurations.
phys-paris-1# geopg stop -e local protectiongroupname
Specifies the scope of the command.
By specifying a local scope, the command operates on the local cluster only.
Note - The property values, such as global and local, are not case sensitive.
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 because the application resource groups are managed and offline.
If you deactivate the protection group, the application resource groups are no longer managed, clearing the Error state.
phys-paris-1# geops update partnershipname
Note - You need to perform this step only once, even if you are resynchronizing multiple protection groups.
For more information about synchronizing partnerships, see Resynchronizing a Partnership in Oracle Solaris Cluster Geographic Edition System Administration Guide.
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.
phys-paris-1# geopg update protectiongroupname
For more information about synchronizing protection groups, see Resynchronizing an Oracle Data Guard Protection Group.
phys-paris-1# geopg validate protectiongroupname
For more information, see How to Validate an Oracle Data Guard Protection Group.
When you activate a protection group, the protection group's application resource groups are also brought online.
phys-paris-1# geopg start -e global protectiongroupname
Specifies the scope of the command.
By specifying a global scope, the command operates on both clusters where the protection group is located.
Note - The property values, such as global and local, are not case sensitive.
Specifies the name of the protection group.
![]() | Caution - Do not use the -n option because the data needs to be synchronized from the current primary cluster, cluster-newyork, to the current standby cluster, cluster-paris. Because the protection group has a role of secondary, the data is synchronized from the current primary cluster, cluster-newyork, to the current standby cluster, cluster-paris. For more information about the geopg start command, see How to Activate an Oracle Data Guard Protection Group. |
phys-newyork-1# geoadm status
Refer to the Protection Group section of the output.
phys-newyork-1# clresource status -v ODGprotectiongroupname-odg-rep-rs
Follow this procedure to restart an application on the original primary cluster, cluster-paris, after the data on the cluster has been resynchronized with the data on the current primary cluster, cluster-newyork.
The failback procedures apply only to clusters in a partnership. You need to perform the following procedure only once for each partnership.
Before You Begin
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 is assigned the primary role.
The protection group on cluster-paris has either the primary role or the secondary role, depending on whether the cluster-paris cluster could be reached during the takeover from the cluster-newyork cluster.
For more information about restarting a cluster, see Booting a Cluster in Oracle Solaris Cluster Geographic Edition System Administration Guide.
Refer to the Oracle documentation, which describes how to perform this step.
oracle (phys-paris-1)$ dgmgrl sys/sysdba_password@sales-svc DGMGRL> show configuration;
If the original primary cluster, cluster-paris, is working correctly, the show configuration command displays the SUCCESS state.
If the original primary cluster was down at the point of failure, it is marked as a deactivated primary cluster. If the original primary cluster was up at the point of failure, it is marked as a deactivated secondary.
The cluster cluster-paris forfeits its own configuration and replicates the cluster-newyork configuration locally. Resynchronize both the partnership and protection group configurations.
phys-paris-1# geops update partnershipname
Note - You need to perform this step only once for each partnership, even if you are performing a failback switchover 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.
phys-paris-1# geoadm status
phys-paris-1# geopg stop -e local protectiongroupname
Specifies the scope of the command.
By specifying a local scope, the command operates on the local cluster only.
Note - The property values, such as global and local, are not case sensitive.
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 because the application resource groups are managed and offline.
If you deactivate the protection group, the application resource groups are no longer managed, clearing the Error state.
phys-paris-1# geoadm status
Because the local role of the protection group on the cluster-newyork cluster is now primary, this step ensures that the role of the protection group on the cluster-paris cluster becomes secondary.
phys-paris-1# geopg update protectiongroupname
For more information about synchronizing protection groups, see Resynchronizing an Oracle Data Guard Protection Group.
A protection group cannot be started when it is in an Error state. Ensure that the protection group is not in an Error state.
phys-paris-1# geopg validate protectiongroupname
For more information, see How to Validate an Oracle Data Guard Protection Group.
When you activate a protection group, its application resource groups are also brought online.
phys-paris-1# geopg start -e global protectiongroupname
Specifies the scope of the command.
By specifying a global scope, the command operates on both clusters where the protection group is located.
Note - The property values, such as global and local, are not case sensitive.
Specifies the name of the protection group.
phys-newyork-1# geoadm status
Refer to the Protection Group section of the output.
phys-newyork-1# clresource status -v ODGprotectiongroupname-odg-rep-rs
phys-paris-1# geoadm status … phys-newyork-1# geoadm status …
phys-node-n# geopg switchover [-f] -m cluster-paris protectiongroupname
For more information, see How to Switch Over an Oracle Data Guard Protection Group From the Primary to the Standby Cluster.
The cluster-paris cluster resumes its original role as primary cluster for the protection group.
phys-node-n# geoadm status
Verify that the protection group is now primary on cluster-paris and secondary on cluster-newyork and that the states that are shown for the Data replication and the Resource groups properties are OK on both clusters.
phys-node-n# clresourcegroup status -v resourcegroupname # clresource status -v ODGConfigurationName-odg-rep-rs
Refer to the Status and Status Message fields that are presented for the Oracle Data Guard Broker configuration that 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 Oracle Data Guard Data Replication.
Follow this procedure to restart an application on the original primary cluster, cluster-paris, and to use the current data on the original primary cluster.
Note - Any updates that occurred on the standby 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 for each partnership.
Note - Conditionally, you can resume using the data on the original primary cluster-paris. However, 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
Before you begin the failback takeover procedure, the clusters must have the following roles:
The protection group on cluster-newyork is assigned the primary role.
The protection group on cluster-paris has either the primary role or secondary role, depending on whether the protection group was reached during the takeover.
For more information about restarting a cluster, see Booting a Cluster in Oracle Solaris Cluster Geographic Edition System Administration Guide.
Refer to the Oracle documentation, which describes how to perform this step.
Note - You might need to use the dgmgrl command to remove and recreate the Oracle Data Guard Broker configuration.
oracle (phys-paris-1)$ dgmgrl sys/sysdba_password@sales-svc DGMGRL> show configuration;
If the original primary cluster, cluster-paris, is working correctly, the show configuration command displays the SUCCESS state.
If the original primary cluster was up at the point of failure, it is marked as a deactivated secondary cluster. Also, the original standby cluster is marked as an activated primary.
If the original primary cluster was down at the point of failure, it is marked as a deactivated primary cluster. Also, the original standby cluster is marked as an activated primary.
phys-newyork-1# geopg stop -e local protectiongroupname
phys-newyork-1# geopg update protectiongroupname
The roles are now correct, but both clusters are marked as deactivated.
For more information about synchronizing protection groups, see How to Resynchronize an Oracle Data Guard Protection Group.
Ensure that the protection group is not in an Error state. You cannot start a protection group when the protection group is in an Error state.
phys-paris-1# geopg validate protectiongroupname phys-newyork-1# geopg validate protectiongroupname
For more information, see How to Validate an Oracle Data Guard Protection Group.
# geopg start -e global protectiongroupname
Once the protection groups are activated on both clusters, you have successfully performed the failback takeover.
phys-newyork-1# geoadm status
phys-paris-1# geopg takeover [-f] protectiongroupname
cluster-newyork# geopg validate protectiongroupname
For more information, see How to Validate an Oracle Data Guard Protection Group.
cluster-newyork# geopg start -e global protectiongroupname
Once the protection groups are activated on both clusters, you have successfully performed the failback takeover.
phys-newyork-1# geopg stop -e local protectiongroupname
phys-newyork-1# geopg takeover -f protectiongroupname
phys-paris-1# geopg validate protectiongroupname phys-newyork-1# geopg validate protectiongroupname
For more information, see How to Validate an Oracle Data Guard Protection Group.
# geopg start -e global protectiongroupname
Once the protection groups are activated on both clusters, you have successfully performed the failback takeover.