Connect the original primary cluster after a lossless failover

Last Updated：2023-08-18 09:26:34 Updated

This topic describes how to connect the original primary cluster after a lossless failover.

Prerequisites

You have determined, based on the initial status of the original primary cluster, 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 operations:

Recover the original primary cluster.

Before the original primary cluster is recovered, all the servers in the original primary cluster must be in down status. This can ensure that the data of the original primary cluster is consistent with that of the new primary cluster.

All the servers in the original primary cluster must start by using the -m disabled_cluster parameter during the recovery of the original primary cluster. After the original primary cluster is started, it automatically enters the DISABLED status. The original primary cluster in the DISABLED status 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 the servers in the original primary cluster do not start by using the -m disabled_cluster parameter, the original primary cluster will generate new logs, causing a connection failure or data checksum error.

Specify the -m disabled_cluster parameter on all the servers of the original primary cluster to start the OBServer.
```
bin/observer -m disabled_cluster
```
After the original primary cluster is recovered, it is in the PRIMARY role but DISABLED state.
```
obclient> SELECT CLUSTER_ID, CLUSTER_ROLE, CLUSTER_STATUS FROM V$OB_CLUSTER;
+------------+--------------+----------------+
| CLUSTER_ID | CLUSTER_ROLE | CLUSTER_STATUS |
+------------+--------------+----------------+
|          1          | PRIMARY          | DISABLED             |
+------------+--------------+----------------+
1 row in set
```

Switch the original primary cluster to the standby role.

Run the following command on the original primary cluster, to switch it to the standby role:

obclient> ALTER SYSTEM CONVERT TO PHYSICAL STANDBY;

Run the following command 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 set

in 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 run the following command to enable synchronization to the standby cluster:
```
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 set

Follow-up processing

The original primary cluster is connected and switched to the standby role.

You can log on to the standby cluster to verify its role.

obclient> SELECT CLUSTER_ID, CLUSTER_ROLE, CLUSTER_STATUS FROM V$OB_CLUSTER;