Failover

When the primary tenant becomes unavailable, you can switch a standby tenant to the PRIMARY role to provide services.

Limitations

• When you perform a failover operation, all log stream replicas of the standby tenant must be online. Otherwise, you must wait until the offline replicas are permanently offline.

  You can log on to the standby tenant or the sys tenant of the cluster where the standby tenant resides and query the DBA_OB_LS or CDB_OB_LS view to check whether all log stream replicas are online. For more information about log stream replicas, see About replicas.

• The failover operation does not check the status of the primary tenant. Therefore, in addition to disaster recovery upon a failure of the primary tenant, the failover operation also applies to a snapshot of the primary tenant created at a specific point in time for subsequent business verification.

Background information

The failover operation modifies log files but not data files.

Each OceanBase Database tenant has multiple log streams, and the failover operation must ensure data consistency. Therefore, the system selects a timestamp with the smallest system change number (SCN) from the synchronization timestamps of all log streams as the failover timestamp. After the failover, all log streams of the tenant are rolled back to the timestamp.

Procedure

1. Log on as the administrator to the standby tenant or the sys tenant of the cluster where the standby tenant resides.

2. Execute the failover statement to switch the standby tenant to the PRIMARY role.

   • Execute the following statement in the sys tenant of the cluster where the standby tenant resides to switch the standby tenant to the PRIMARY role:

     ALTER SYSTEM ACTIVATE STANDBY TENANT = tenant_name;
     

   • Execute the following statement in the standby tenant to switch it to the PRIMARY role:

     ALTER SYSTEM ACTIVATE STANDBY;
     

3. Query the DBA_OB_TENANTS view to check whether the original standby tenant is switched to the PRIMARY role.

   • Query the view from the sys tenant of the cluster where the standby tenant resides

     SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
     

   • Query the view from the standby tenant

     MySQL mode:

     SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
     

     Oracle mode:

     SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM SYS.DBA_OB_TENANTS;
     

   The query result is as follows:

   +-----------------+-------------+-------------+-------------------+
   | TENANT_NAME     | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
   +-----------------+-------------+-------------+-------------------+
   | standby_tenant  | USER        | PRIMARY     | NORMAL            |
   +-----------------+-------------+-------------+-------------------+
   1 row in set
   

   In the query result, the value of TENANT_ROLE is PRIMARY and that of SWITCHOVER_STATUS is NORMAL, which indicates that the standby tenant is switched to the PRIMARY role.

Considerations

The failover operation restores the synchronized data of all log streams to the consistency timestamp. This ensures that the data of all log streams before the timestamp is complete. Therefore, after a failover operation is performed, the following rules apply:

• The original primary tenant cannot be a standby tenant of the new primary tenant.

• If the logs of a third-party standby tenant are synchronized to a timestamp that exceeds the consistency timestamp, you cannot use the third-party standby tenant as a standby tenant of the new primary tenant. For ease of management, we recommend that you do not use a third-party standby tenant as a standby tenant of the new primary tenant.