Failover

If the primary tenant is unavailable, the standby tenant can be switched to become the primary tenant and continue to provide services.

Limitations

• When performing a failover, all replicas of the standby tenant's log streams must be online. Otherwise, it is necessary to wait for the corresponding replica to be permanently offline.

  The availability of log stream replicas can be checked separately by the DBA_OB_LS or CDB_OB_LS view for the standby tenant or the sys tenant of the cluster where the standby tenant is located. For more information about log stream replicas, see About replicas.

• During a failover, the state of the corresponding primary tenant is not checked. Therefore, besides the disaster recovery requirement for a failed primary tenant, the failover operation can also be used in scenarios where an independent primary tenant needs to be snapshot at a certain point in time for subsequent business verification.

Background information

The failover operation only modifies log files and does not modify data files.

Since each tenant in the OceanBase database has multiple log streams and the failover operation needs to achieve data consistency after the operation is completed, the system will select the minimum system change number (SCN) value among the synchronization checkpoints of all log streams as the execution checkpoint for failover. After the failover operation is executed, all log streams under the tenant will be rolled back to this checkpoint.

Procedure

1. Log in to the standby tenant or the sys tenant of the cluster where the standby tenant is located, using the administrator.

2. Switch the standby tenant to become the primary tenant.

   • For the sys tenant of the cluster where the standby tenant is located to switch the standby tenant to become the primary tenant:

     ALTER SYSTEM ACTIVATE STANDBY TENANT = tenant_name;
     

   • For the standby tenant to switch itself to become the primary tenant:

     ALTER SYSTEM ACTIVATE STANDBY;
     

3. Query the DBA_OB_TENANTS view to check whether the standby tenant has been switched to become the primary tenant.

   • For the sys tenant of the cluster where the standby tenant is located, query the view:

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

   • For the standby tenant, query the view:

     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;
     

   An example of query result is as follows:

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

   According to the query result, the TENANT_ROLE of the standby tenant becomes PRIMARY and the SWITCHOVER_STATUS is NORMAL, which indicate that the standby tenant has successfully switched to become the primary tenant.

Considerations

Since the failover operation restores the synchronized data of all log streams to the consistency checkpoint, this ensures that the data of all log streams before this checkpoint is intact. Therefore, note the following after performing a failover:

• 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 checkpoint that exceeds the consistency checkpoint, the third-party standby tenant cannot be used as a standby tenant of the new primary tenant. For ease of management, it is not recommended for third-party standby tenants to be the standby tenants of the new primary tenant.