This topic describes how to connect the original primary cluster after a lossless failover.
Prerequisites
Based on the initial status of the original primary cluster, you are sure that the original primary cluster can be connected after a lossless failover. Determine whether the original primary cluster can be connected based on the following rules:
The original primary cluster is in MAXIMUM PROTECTION mode, and the standby cluster is at the MAXIMUM PROTECTION level. In this case, after the standby cluster performs a lossless failover when the primary cluster is unavailable, the original primary cluster can be connected.
The original primary cluster is in MAXIMUM PROTECTION mode, the standby cluster is at the MAXIMUM PROTECTION level, and the two clusters are isolated from each other. After the protection mode of the primary cluster is manually modified, the primary cluster continues to provide services, and the standby cluster is still at the MAXIMUM PROTECTION level. In this case, after the standby cluster performs a lossless failover when the primary cluster is unavailable, the original primary cluster cannot be connected.
The original primary cluster is in MAXIMUM AVAILABILITY mode, and both the original primary cluster and the standby cluster are at the MAXIMUM AVAILABILITY level. In this case, after the standby cluster performs a lossless failover when the primary cluster is unavailable, the original primary cluster can be connected.
The original primary cluster is in MAXIMUM AVAILABILITY mode, both the original primary cluster and the standby cluster are at the MAXIMUM AVAILABILITY level, and the two clusters are isolated from each other. The original primary cluster automatically degrades to the MAXIMUM PERFORMANCE level to asynchronously transfer logs to the standby cluster, and the standby cluster is still at the MAXIMUM AVAILABILITY level. In this case, after the standby cluster performs a lossless failover when the primary cluster is unavailable, the original primary cluster cannot be connected.
Notice
Data consistency is not verified during connection to the original primary cluster. Therefore, data consistency between the primary cluster and the standby cluster must be manually verified before the failover. If data is inconsistent between the primary cluster and the standby cluster before the failover, a data checksum error may occur after the original primary cluster is connected after the failover.
Procedure
To connect the original primary cluster, perform the following steps:
Restore the original primary cluster.
Before the original primary cluster is restored, all OBServer nodes in the original primary cluster must be disabled. This can ensure that data of the original primary cluster is consistent with that of the new primary cluster.
All OBServer nodes in the original primary cluster must start by using the -m disabled_cluster option during the restore of the original primary cluster. After the original primary cluster is started, it automatically enters the
DISABLEDstatus. The original primary cluster in theDISABLEDstatus does not receive data writes or generate new logs. This ensures that the original primary cluster is in the same state as the new primary cluster. If all OBServer nodes in the original primary cluster do not start by using the -m disabled_cluster option, the original primary cluster will generate new logs, causing a connection failure or data checksum error.Specify the
-m disabled_clusteroption on all OBServer nodes in the original primary cluster to start the observer process.bin/observer -m disabled_clusterAfter the original primary cluster is restored, it is in the
DISABLEDstate but its role isPRIMARY.obclient> SELECT CLUSTER_ID, CLUSTER_ROLE, CLUSTER_STATUS FROM V$OB_CLUSTER; +------------+--------------+----------------+ | CLUSTER_ID | CLUSTER_ROLE | CLUSTER_STATUS | +------------+--------------+----------------+ | 1 | PRIMARY | DISABLED | +------------+--------------+----------------+ 1 row in setSwitch the original primary cluster to the standby role.
Execute the following statement on the original primary cluster to switch it to the standby role:
obclient> ALTER SYSTEM CONVERT TO PHYSICAL STANDBY;Execute the following statement to verify the role of the original primary cluster:
obclient> SELECT CLUSTER_ID, CLUSTER_ROLE, CLUSTER_STATUS FROM V$OB_CLUSTER; +------------+------------------+----------------+ | CLUSTER_ID | CLUSTER_ROLE | CLUSTER_STATUS | +------------+------------------+----------------+ | 1 | PHYSICAL STANDBY | DISABLED | +------------+------------------+----------------+ 1 row in setIn the new primary cluster, enable synchronization to the original primary cluster, which is now a standby cluster.
Log on to the new primary cluster and execute the following statement to enable synchronization to standby clusters:
obclient> ALTER SYSTEM ENABLE CLUSTER SYNCHRONIZATION 'obcluster' CLUSTER_ID=1;Verify that synchronization is enabled.
obclient> SELECT CLUSTER_ID, CLUSTER_ROLE, CLUSTER_STATUS FROM V$OB_STANDBY_STATUS; +------------+------------------+----------------+ | CLUSTER_ID | CLUSTER_ROLE | CLUSTER_STATUS | +------------+------------------+----------------+ | 1 | PHYSICAL STANDBY | VALID | +------------+------------------+----------------+ 1 row in setFor more information about the
v$ob_standby_statusview, see v$ob_standby_status.
What to do next
The original primary cluster is connected and switched to the standby role.
You can log on to the standby cluster to check its role.
obclient> SELECT CLUSTER_ID, CLUSTER_ROLE, CLUSTER_STATUS FROM V$OB_CLUSTER;
+------------+------------------+----------------+
| CLUSTER_ID | CLUSTER_ROLE | CLUSTER_STATUS |
+------------+------------------+----------------+
| 1 | PHYSICAL STANDBY | VALID |
+------------+------------------+----------------+
1 row in set