Switchover

If the primary tenant is available, you can perform a switchover to switch the roles between the primary tenant and one of the standby tenants to ensure data consistency.

The following sections describe how to perform a switchover based on the two deployment modes of the physical standby tenant.

Limitations

• You cannot switch the tenant role of the system tenant (sys). The role of the system tenant is always PRIMARY.

• Before you switch a standby tenant to the primary tenant, all replicas of the log streams of the standby tenant must be online. Otherwise, you need to wait for the corresponding replicas to go offline permanently. You can query the DBA_OB_LS view of the standby tenant or the CDB_OB_LS view of the sys tenant in the standby tenant or the cluster where the standby tenant resides to check whether all replicas of the log streams are online. For more information about log stream replicas, see Replica introduction.

• You cannot execute the Switchover command in a session established by using a service name. For more information about services, see Create a service.

Standby tenant for physical standby databases over a network

In this scenario, switchover comprises three stages: switchover from primary tenant to standby tenant, switchover from standby tenant to primary tenant, and setting the log restore source for the original primary tenant.

1. Switchover from the primary tenant to the standby tenant.

   1. Log in to the sys tenant of the primary tenant or the primary tenant cluster as the admin user.

   2. Execute the SWITCHOVER TO STANDBY VERIFY command to check whether the SWITCHOVER command can be executed.

      • Log in to the sys tenant of the primary tenant cluster, and execute the SWITCHOVER TO STANDBY VERIFY command.

        ALTER SYSTEM SWITCHOVER TO STANDBY TENANT [=] tenant_name VERIFY;
        

        Sample code:

        obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql VERIFY;
        

      • Log in to the primary tenant, and execute the SWITCHOVER TO STANDBY VERIFY command.

        obclient> ALTER SYSTEM SWITCHOVER TO STANDBY VERIFY;
        

        If the OK is returned after the command is executed, the verification is successful and the command can be executed in the next step.

        If an error is returned, resolve the issue based on the error message provided in the prompt and then reexecute the command. For more information, see Switchover or failover-related issues.

   3. After verification is completed, switchover from the primary tenant to the standby tenant.

      • Log in to the sys tenant of the primary tenant cluster and execute the switchover command to switchover from the primary tenant to the standby tenant.

        ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = tenant_name;
        

        Sample code:

        obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql;
        

      • Log in to the primary tenant and execute the switchover command to switchover from the primary tenant to the standby tenant.

        obclient> ALTER SYSTEM SWITCHOVER TO STANDBY;
        

   4. Query the DBA_OB_TENANTS view to verify whether the primary tenant has been switchover to the standby tenant.

      • Log in to the sys tenant of the primary tenant cluster and query the view.

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

      • Log in to the primary tenant and query the view.

        In MySQL mode:

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

        In Oracle mode:

        obclient> 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 |
      +-------------+-------------+-------------+-------------------+
      | mysql       | USER        | STANDBY     | NORMAL            |
      +-------------+-------------+-------------+-------------------+
      1 row in set
      

      If the TENANT_ROLE is STANDBY and the SWITCHOVER_STATUS is NORMAL, the switchover from the primary tenant to the standby tenant is successful.

2. Switchover from the standby tenant to the primary tenant.

   1. Log in to the sys tenant of the standby tenant or the standby tenant cluster as the admin user.

   2. Execute the switchover command to switchover from the standby tenant to the primary tenant.

      • Log in to the sys tenant of the standby tenant cluster and execute the switchover command to switchover from the standby tenant to the primary tenant.

        ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = tenant_name;
        

        Sample code:

        obclient> ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = standby1;
        

      • Log in to the standby tenant and execute the switchover command to switchover from the standby tenant to the primary tenant.

        obclient> ALTER SYSTEM SWITCHOVER TO PRIMARY;
        

   3. Query the DBA_OB_TENANTS view to verify whether the standby tenant has been switchover to the primary tenant.

      • Log in to the sys tenant of the standby tenant cluster and query the view.

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

      • Log in to the standby tenant and query the view.

        In MySQL mode:

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

        In Oracle mode:

        obclient> 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 |
      +-----------------+-------------+-------------+-------------------+
      | standby1        | USER        | PRIMARY     | NORMAL            |
      +-----------------+-------------+-------------+-------------------+
      1 row in set
      

      If the TENANT_ROLE of the original standby tenant is PRIMARY and the SWITCHOVER_STATUS is NORMAL, the switchover from the standby tenant to the primary tenant is successful.

3. Set a log restore source for the original primary tenant.

   You can run this step before or after the switchover operation.

   1. Log in to the sys tenant of the original primary tenant or the original primary tenant cluster as the admin user.

   2. Execute the following command to set a log restore source.

      • Log in to the sys tenant of the original primary tenant cluster and execute the following command to set a log restore source for the original primary tenant:

        ALTER SYSTEM SET LOG_RESTORE_SOURCE ='SERVICE=$ip_list USER=$user_name@$tenant_name PASSWORD=$password' TENANT = tenant_name;
        

      • Log in to the original primary tenant and execute the following command to set a log restore source for the original primary tenant:

        ALTER SYSTEM SET LOG_RESTORE_SOURCE ='SERVICE=$ip_list USER=$user_name@$tenant_name PASSWORD=$password';
        

      The parameters are described as follows:

      • $ip_list: the IP address and SQL port number of the OBServer node where the new primary tenant is deployed. Specify only one of the OBServer nodes.
      • $user_name: the user created in the new primary tenant to access system views.
      • $tenant_name: the name of the new primary tenant.
      • $password: the password of the user created in the new primary tenant to access system views.

      Example:

      obclient> ALTER SYSTEM SET LOG_RESTORE_SOURCE = 'SERVICE=11.xx.xx.22:17855;11.xx.xx.23:17857;11.xx.xx.24:17859 USER=rep_user2@standby_tenant PASSWORD=******' TENANT = mysql;
      

      obclient> ALTER SYSTEM SET LOG_RESTORE_SOURCE = 'SERVICE=11.xx.xx.22:17855;11.xx.xx.23:17857;11.xx.xx.24:17859 USER=rep_user2@standby_tenant PASSWORD=******';
      

      For more information, see Set a log restore source.

   3. After the log restore source is set, query the DBA_OB_TENANTS view to check whether the original primary tenant is synchronizing log data in real time.

      After the switchover from the primary tenant to the standby tenant, log continuous synchronization is automatically enabled. Therefore, you do not need to perform any special operations. You can query the DBA_OB_TENANTS view to confirm.

      • Log in to the sys tenant of the original primary tenant cluster and query the view.

        # Query the user tenant ID. If the ID is even, it is the user tenant.
        obclient> SELECT TENANT_ID, SYNC_SCN FROM oceanbase.DBA_OB_TENANTS;
        # Query information about the user tenant.
        obclient> SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS, SCN_TO_TIMESTAMP(SYNC_SCN), RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_ID = $user_tenant_id;
        

      • Query the original primary tenant view.

        MySQL mode:

        obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS, SCN_TO_TIMESTAMP(SYNC_SCN), RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;
        

        Oracle mode:

        obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS, SCN_TO_TIMESTAMP(SYNC_SCN), RECOVERY_UNTIL_SCN FROM SYS.DBA_OB_TENANTS;
        

      The query result in MySQL mode is as follows:

      +-------------+-------------+-------------+-------------------+----------------------------+---------------------+
      | TENANT_NAME | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS | SCN_TO_TIMESTAMP(SYNC_SCN) | RECOVERY_UNTIL_SCN  |
      +-------------+-------------+-------------+-------------------+----------------------------+---------------------+
      | mysql       | USER        | STANDBY     | NORMAL            | 2023-04-18 13:46:20.887793 | 4611686018427387903 |
      +-------------+-------------+-------------+-------------------+----------------------------+---------------------+
      1 row in set
      

      If the value of the RECOVERY_UNTIL_SCN column is equal to the maximum SCN (4611686018427387903), the original primary tenant is continuously synchronizing logs. Otherwise, the original primary tenant is not continuously synchronizing logs.

Physical standby database based on log archiving

In the physical standby database based on log archiving scenario, switchover mainly includes the following three stages: enable log archiving mode for the standby tenant --> switch the primary tenant to the standby tenant --> switch the standby tenant to the primary tenant.

1. Enable log archiving mode for the standby tenant.

   In the physical standby database based on log archiving scenario, after the switchover operation is executed, the original primary tenant needs to continuously read the archive logs of the new primary tenant (original standby tenant) to synchronize all modification operations on the new primary tenant (original standby tenant). Therefore, the new primary tenant (original standby tenant) must be enabled for log archiving mode. In addition, to ensure the continuity of logs after switchover, the new primary tenant (original standby tenant) must be enabled for log archiving before the switchover operation.

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

   2. Configure the archive destination of the standby tenant.

      Notice

      Different tenants need to use different archive paths.

      Configure the archive destination by setting the LOCATION, PIECE_SWITCH_INTERVAL, and BINDING attributes.

      • Configure the archive destination of the standby tenant in the sys tenant of the cluster where the standby tenant is located.

        ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=archive_path [PIECE_SWITCH_INTERVAL=piece_switch_interval] [BINDING=archive_mode]' TENANT = tenant_name;
        

      • Configure the archive destination of the standby tenant.

        ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=archive_path [PIECE_SWITCH_INTERVAL=piece_switch_interval] [BINDING=archive_mode]';
        

      The following table describes the parameters.

      • LOCATION: specifies the archive destination. OceanBase Database supports the NFS and Alibaba Cloud OSS media types for archive destinations.

      • BINDING: specifies the priority mode for archive and business operations. The supported modes are Optional and Mandatory. If this parameter is not specified, the default value Optional is used.

        • In Optional mode, business operations take precedence. In this mode, when the speed of log archiving cannot keep up with the speed of log generation, some logs may be recycled before they are archived, which may cause a data stream interruption.

        • In Mandatory mode, log archiving takes precedence. In this mode, if the speed of log archiving cannot keep up with the speed of user data writing, users may be unable to write data.

      • The PIECE_SWITCH_INTERVAL parameter specifies the piece switching cycle, which ranges from [1d, 7d]. If this parameter is not specified, the default value 1d is used.

      Assume that the archive media is NFS, the archive path of the standby tenant is file:///data/1/standby2_archive2/, and the archive mode is Optional. The following example shows the configuration:

      obclient> ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=file:///data/1/standby2_archive2/ BINDING=optional' TENANT = standby2;
      

      obclient> ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=file:///data/1/standby2_archive2/ BINDING=optional';
      

   3. Enable log archiving mode for the standby tenant.

      • Enable log archiving mode for the standby tenant in the sys tenant of the cluster where the standby tenant is located.

        Example:

        obclient> ALTER SYSTEM ARCHIVELOG TENANT = standby2;
        

        In this example, standby2 is the name of the standby tenant. Replace it with the actual name in your environment.

      • Enable log archiving mode for the standby tenant.

        obclient> ALTER SYSTEM ARCHIVELOG;
        

   4. Check whether the archive status of the standby tenant is DOING.

      • Query the view in the sys tenant of the cluster where the standby tenant is located.

        obclient> SELECT DEST_ID, ROUND_ID, DEST_NO, STATUS, CHECKPOINT_SCN, CHECKPOINT_SCN_DISPLAY, PATH FROM oceanbase.CDB_OB_ARCHIVELOG;
        

      • Query the view of the standby tenant.

        MySQL mode:

        obclient> SELECT DEST_ID, ROUND_ID, DEST_NO, STATUS, CHECKPOINT_SCN, CHECKPOINT_SCN_DISPLAY, PATH FROM oceanbase.DBA_OB_ARCHIVELOG;
        

        Oracle mode:

        obclient> SELECT DEST_ID, ROUND_ID, DEST_NO, STATUS, CHECKPOINT_SCN, CHECKPOINT_SCN_DISPLAY, PATH FROM SYS.DBA_OB_ARCHIVELOG;
        

        The following example shows the query result in MySQL mode:

        +---------+----------+---------+--------+---------------------+----------------------------+---------------------------------------+
        | DEST_ID | ROUND_ID | DEST_NO | STATUS | CHECKPOINT_SCN      | CHECKPOINT_SCN_DISPLAY     | PATH                                 -|
        +---------+----------+---------+--------+---------------------+----------------------------+---------------------------------------+
        |    1001 |        1 |       0 | DOING  | 1680265982125159110 | 2023-03-31 20:33:02.125159 | file:///data/1/standby2_archive2      -|
        +---------+----------+---------+--------+---------------------+----------------------------+---------------------------------------+
        1 row in set
        

      If the STATUS value is DOING, the archive status is normal. The CHECKPOINT_SCN and CHECKPOINT_SCN_DISPLAY values indicate the archive progress.

      For more information about how to view the archive status, see View the archive progress.

2. Switch the primary tenant to the standby tenant.

   1. Log in to the database as the tenant administrator of the primary tenant or the sys tenant of the cluster where the primary tenant is located.

   2. Execute the SWITCHOVER TO STANDBY VERIFY statement to verify whether the SWITCHOVER statement can be executed.

      • Execute the SWITCHOVER TO STANDBY VERIFY statement in the sys tenant of the cluster where the primary tenant is located.

        ALTER SYSTEM SWITCHOVER TO STANDBY TENANT [=] tenant_name VERIFY;
        

        Example:

        obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql2 VERIFY;
        

      • Execute the SWITCHOVER TO STANDBY VERIFY statement in the primary tenant.

        obclient> ALTER SYSTEM SWITCHOVER TO STANDBY VERIFY;
        

        If the execution result is OK, the verification is successful. You can proceed to the next step.

        If an error is returned, refer to the text information in the error message and Switchover or failover issues for troubleshooting. After the issue is resolved, execute this statement again.

   3. Execute the primary-to-standby switchover command to switch the primary tenant to the standby tenant.

      • Switch the primary tenant to the standby tenant in the sys tenant of the cluster where the primary tenant is located.

        ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = tenant_name;
        

        Example:

        obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql2;
        

      • Switch the primary tenant to the standby tenant.

        obclient> ALTER SYSTEM SWITCHOVER TO STANDBY;
        

   4. Query the DBA_OB_TENANTS view to confirm whether the primary tenant has been switched to the standby tenant.

      • Query the view in the sys tenant of the cluster where the primary tenant is located.

        obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
        FROM oceanbase.DBA_OB_TENANTS 
        WHERE TENANT_NAME='mysql2';
        

      • Query the view of the primary tenant.

        MySQL mode:

        obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
        FROM oceanbase.DBA_OB_TENANTS 
        WHERE TENANT_NAME='mysql2';
        

        Oracle mode:

        obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
        FROM SYS.DBA_OB_TENANTS 
        WHERE TENANT_NAME='mysql2';
        

      The following example shows the query result:

      +-----------+-------------+-------------+-------------+-------------------+
      | TENANT_ID | TENANT_NAME | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
      +-----------+-------------+-------------+-------------+-------------------+
      |      1004 | mysql2      | USER        | STANDBY     | NORMAL            |
      +-----------+-------------+-------------+-------------+-------------------+
      1 row in set
      

      Based on the query result, the value of TENANT_ROLE for the primary tenant has been changed from PRIMARY to STANDBY, and the value of SWITCHOVER_STATUS has been changed from PLANNED to NORMAL, which indicates that the primary tenant has been successfully switched to a standby tenant.

   5. Query the SYNCHRONIZED field in the V$OB_ARCHIVE_DEST_STATUS view and wait for the primary tenant to complete the archiving.

      In a physical standby database scenario based on log archiving, the standby tenant must read the complete logs from the original primary tenant's log archive before it becomes the primary tenant. Because the log archiving operates in asynchronous mode, after the original primary tenant switches to a standby, you must check whether the log archives on the original primary tenant are complete.

      • MySQL mode

        obclient> SELECT * FROM oceanbase.V$OB_ARCHIVE_DEST_STATUS WHERE TENANT_ID = 1004;
        

      • Oracle mode

        obclient> SELECT * FROM SYS.V$OB_ARCHIVE_DEST_STATUS WHERE TENANT_ID = 1004;
        

      The query results in MySQL mode are as follows:

      +-----------+---------+--------------------------------+--------+---------------------+--------------+---------+
      | TENANT_ID | DEST_ID | PATH                           | STATUS | CHECKPOINT_SCN      | SYNCHRONIZED | COMMENT |
      +-----------+---------+--------------------------------+--------+---------------------+--------------+---------+
      |      1004 |    1001 | file:///data/1/sh_archive      | DOING  | 1684638569520797277 | YES          |         |
      +-----------+---------+--------------------------------+--------+---------------------+--------------+---------+
      1 row in set
      

      The SYNCHRONIZED field indicates whether the archive for the primary tenant has been completed. If the SYNCHRONIZED field shows YES, the archive for the primary tenant has been completed.

      Notice

      Before you perform an switchover, ensure that the value of the SYNCHRONIZED field is YES. Otherwise, after an switchover, data in the new primary tenant may be incomplete.

3. Switch the secondary tenant to primary.

   1. Log in to the database as the administrator of the standby tenant or the sys tenant of the standby tenant.

   2. Execute the switchover primary tenant command to switch the standby tenant to the primary tenant.

      Notice

      Before the switchover command is executed, the system checks whether the standby tenant has synchronized all logs of the recovery source to the primary tenant. Therefore, the execution time of the switchover command depends on the synchronization progress between the primary and standby tenants.

      • Switch the standby tenant cluster to the primary tenant cluster in the sys tenant.

        ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = tenant_name;
        

        Example:

        obclient> ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = standby2;
        

      • Change the current tenant to the primary tenant for the new primary tenant.

        obclient> ALTER SYSTEM SWITCHOVER TO PRIMARY;
        

   3. Query the DBA_OB_TENANTS view to confirm whether the standby tenant has become the primary tenant.

      • Query the view of the sys tenant in the source cluster.

        obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
        FROM oceanbase.DBA_OB_TENANTS 
        WHERE TENANT_NAME='standby2';
        

      • Master tenant query view

        MySQL Mode:

        obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
        FROM oceanbase.DBA_OB_TENANTS 
        WHERE TENANT_NAME='standby2'';
        

        Oracle mode:

        obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
        FROM SYS.DBA_OB_TENANTS 
        WHERE TENANT_NAME='standby2'';
        

      Here is an example of the query result:

      +-----------+----------------------------+-------------+-------------+-------------------+
      | TENANT_ID | TENANT_NAME                | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
      +-----------+----------------------------+-------------+-------------+-------------------+
      |      1006 | standby2                   | USER        | PRIMARY     | NORMAL            |
      +-----------+----------------------------+-------------+-------------+-------------------+
      1 row in set
      

      After you execute the query, if the TENANT_ROLE is changed to PRIMARY and the SWITCHOVER_STATUS is set to NORMAL, the standby tenant has been switched to the primary tenant.

4. Configure the original primary tenant as a recovery source to receive the archive logs from the new primary tenant.

   If you have not configured a log restore source for the original master tenant before the switchover, the log synchronization checkpoint of the original master tenant remains at the point in time when you executed the switchover. To resolve this issue, you must configure a log restore source for the original master tenant that points to the new master tenant.

   You can execute this operation before or after a switch between primary and standby instances.

   1. Log in as the tenant administrator of the sys tenant of the new standby tenant or original primary tenant (if the new standby tenant is in a different cluster).

   2. Run the following commands to configure the new standby tenant (the original primary tenant) to use the primary tenant as the restore source.

      • In the sys tenant of the new standby tenant's cluster, set the new standby tenant's recovery source.

        ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=archive_path' TENANT = tenant_name;
        

      • A new tenant is set to use the original data of the original tenant as the restore source.

        ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=archive_path';
        

      The LOCATION attribute specifies the archive destination of the new primary tenant.

      Here is an example:

      obclient> ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=file:///data/1/standby2/archive2' TENANT = mysql2;
      
      obclient> ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=file:///data/1/standby2/archive2';
      

   3. Query the DBA_OB_TENANTS view to confirm whether the original primary tenant is in continuous synchronization mode.

      After the log restore source is set, log continuous synchronization is automatically enabled after the primary tenant switches to the standby tenant. No special processing is required. You can confirm this by querying the DBA_OB_TENANTS view.

      • sys tenant view in the original parent cluster

        obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS, SCN_TO_TIMESTAMP(SYNC_SCN), RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;
        

      • The original master tenant can query the view

        MySQL mode:

        obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS, SCN_TO_TIMESTAMP(SYNC_SCN), RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;
        

        Oracle Mode:

        obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS, SCN_TO_TIMESTAMP(SYNC_SCN), RECOVERY_UNTIL_SCN FROM SYS.DBA_OB_TENANTS;
        

      In MySQL mode, the query result is as follows:

      +-------------+-------------+-------------+-------------------+----------------------------+---------------------+
      | TENANT_NAME | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS | SCN_TO_TIMESTAMP(SYNC_SCN) | RECOVERY_UNTIL_SCN  |
      +-------------+-------------+-------------+-------------------+----------------------------+---------------------+
      | mysql2      | USER        | STANDBY     | NORMAL            | 2023-05-21 11:41:46.432851 | 4611686018427387903 |
      +-------------+-------------+-------------+-------------------+----------------------------+---------------------+
      

      Based on the query result, if the value in the RECOVERY_UNTIL_SCN column is equal to the maximum SCN (4611686018427387903), the primary tenant is synchronously replicating logs. Otherwise, the primary tenant is not synchronously replicating logs.