Perform a lossless failover

This topic describes how to perform a lossless failover.

Procedure

1. Make sure that the primary cluster is unavailable, which means that all OBServer nodes in the primary cluster are inactive.

   Execute the following statement on the primary cluster. If the returned value of the STATUS field is inactive, all OBServer nodes in the cluster are inactive.

   obclient> SELECT STATUS FROM __ALL_SERVER;
   +----------+
   | STATUS   |
   +----------+
   | inactive |
   +----------+
   1 row in set
   

   Note

   To ensure data security, only one primary cluster can be deployed in the primary/standby cluster configuration. If the primary cluster is available, an error will be returned when you execute the failover statement on a standby cluster. Therefore, to ensure the successful execution of the failover statement, make sure that the primary cluster is unavailable before the failover.

2. Query the protection modes and protection levels of standby clusters and select an appropriate standby cluster.

   obclient> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$OB_CLUSTER;
   +--------------------+--------------------+
   | PROTECTION_MODE    | PROTECTION_LEVEL   |
   +--------------------+--------------------+
   | MAXIMUM PROTECTION | MAXIMUM PROTECTION |
   +--------------------+--------------------+
   1 row in set
   

   Note

   • Only a standby cluster whose PROTECTION_MODE and PROTECTION_LEVEL are both MAXIMUM PROTECTION or MAXIMUM AVAILABILITY can be switched to the primary role. Otherwise, an error will be returned when you execute the failover statement.

   • If data in all partitions of the standby cluster is complete and consistent, you can specify the FORCE option in the failover statement to skip the check for the protection mode and protection level. For example, the failover statement can be ALTER SYSTEM FAILOVER TO 'obcluster' CLUSTER_ID=2 FORCE;.

3. Execute the following statement to switch the standby cluster to the primary role without data loss:

   obclient> ALTER SYSTEM FAILOVER TO 'obcluster' CLUSTER_ID=2;
   

   By default, after you execute the failover statement, the new primary cluster enters the MAXIMUM PERFORMANCE mode, and the original primary cluster and other standby clusters are in the DISABLED state. These clusters must be connected to the new primary cluster.

   • View the protection mode of the new primary cluster

     obclient> SELECT CLUSTER_ID, CLUSTER_ROLE, CLUSTER_STATUS, PROTECTION_MODE, PROTECTION_LEVEL FROM V$OB_CLUSTER;
     +------------+--------------+----------------+---------------------+--------------+
     | CLUSTER_ID | CLUSTER_ROLE | CLUSTER_STATUS | PROTECTION_MODE     | PROTECTION_LEVEL    |
     +------------+--------------+----------------+---------------------+--------------+
     |  2         | PRIMARY      | VALID          | MAXIMUM PERFORMANCE | MAXIMUM PERFORMANCE |
     +------------+--------------+----------------+---------------------+--------------+
     1 row in set
     

   • View the status of the original primary cluster and other standby clusters

     obclient> SELECT CLUSTER_ID, CLUSTER_ROLE, CLUSTER_STATUS FROM V$OB_STANDBY_STATUS;
     +------------+------------------+----------------+
     | CLUSTER_ID | CLUSTER_ROLE     | CLUSTER_STATUS |
     +------------+------------------+----------------+
     |     1      | PHYSICAL STANDBY | DISABLED       |
     +------------+------------------+----------------+
     |     3      | PHYSICAL STANDBY |   DISABLED     |
     +------------+------------------+----------------+
     1 row in set
     

     Note

     Based on the results of the preceding statements, the protection mode of the new primary cluster with a cluster ID of 2 is MAXIMUM PERFORMANCE. The cluster status of the original primary cluster with a cluster ID of 1 and that of the other standby clusters with a cluster ID of 3 are DISABLED. The original primary cluster and the other standby cluster need to be connected to the new primary cluster.

4. Optional. Initiate a major compaction.

   After you perform a lossless failover, we recommend that you initiate a major compaction for a cluster whose compaction version is 1 before you can connect a standby cluster to the new primary cluster. Otherwise, the newly connected standby cluster may malfunction and may not support operations such as primary/standby switchover. For more information about major compaction, see Manually initiate a major compaction.

   You can perform the following steps to view the major compaction version of clusters.

   Log on to the sys tenant of the database as the root user, start the oceanbase database, and then execute the following statement:

   obclient> SELECT * FROM __all_zone WHERE name LIKE '%merge%';
   

   The last_merged_version field in the name column specifies the latest major compaction version of a cluster.

What to do next

After you execute the failover statement, the original primary cluster and other standby clusters are in the DISABLED state. They must be connected to the new primary cluster.

For more information about the connection operation of the original primary cluster, see Connect the original primary cluster after a lossless failover.

For more information about the connection operation of other standby clusters, see Connect other standby clusters after a lossless failover.