Switchover|V4.4.2| docs|Distributed Database

Switchover

Last Updated：2026-03-06 07:02:42 Updated

When the primary tenant is available, you can switch the primary tenant with one of the standby tenants to ensure data consistency.

The following sections provide switchover instructions based on the two deployment modes of the physical standby database.

Limitations

Switching the tenant role of the system tenant (sys) is not supported. The role of the system tenant is always PRIMARY.
Before you switch a standby tenant to the primary tenant, all replicas of all log streams of the standby tenant must be online. Otherwise, you must 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 is located to check whether all replicas of all 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.

Network-based physical standby database

In a network-based physical standby database scenario, switchover mainly includes the following three phases: switch the primary tenant to a standby tenant --> switch the standby tenant to a primary tenant --> set the log restore source for the original primary tenant.

Notice

During a switchover operation, you must first switch the primary tenant to a standby tenant, and then switch the standby tenant to a primary tenant. If you switch the standby tenant to a primary tenant first, the ALTER SYSTEM SWITCHOVER TO PRIMARY command may fail due to a dual-primary tenant issue.

Switch the primary tenant to a standby tenant.
1. Log in to the sys tenant of the primary tenant or the primary tenant cluster as the administrator.
2. Execute the SWITCHOVER TO STANDBY VERIFY command to verify whether the SWITCHOVER command can be executed successfully.
  - The sys tenant of the cluster where the primary tenant resides executes the SWITCHOVER TO STANDBY VERIFY command
```
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT [=] tenant_name VERIFY;
```
    Example:
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql VERIFY;
```
  - The primary tenant executes the SWITCHOVER TO STANDBY VERIFY command
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY VERIFY;
```
    If the command returns OK, the verification passes and you can proceed to the next step.
    
    If an error occurs, refer to Switchover or failover issues for handling based on the error message, and then retry the command.
3. After the verification passes, execute the primary-to-standby switchover command to switch the primary tenant to a standby tenant.
  - The sys tenant of the cluster where the primary tenant resides switches the primary tenant to a standby tenant
```
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = tenant_name;
```
    Example:
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql;
```
  - The primary tenant switches itself to a 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 a standby tenant.
  - The sys tenant of the cluster where the primary tenant resides queries the view
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
```
  - The primary tenant queries the view
    
    MySQL-compatible tenant:
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
```
    In Oracle-compatible tenant:
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM SYS.DBA_OB_TENANTS;
```
  An example of the query result:
```
+-------------+-------------+-------------+-------------------+
| TENANT_NAME | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
+-------------+-------------+-------------+-------------------+
| mysql       | USER        | STANDBY     | NORMAL            |
+-------------+-------------+-------------+-------------------+
1 row in set
```
  In the query result, if TENANT_ROLE is STANDBY and SWITCHOVER_STATUS is NORMAL, the primary-to-standby switchover is successful.
Switch the standby tenant to a primary tenant.
1. Log in to the sys tenant of the standby tenant or the standby tenant cluster as the administrator.
2. Execute the standby-to-primary switchover command to switch the standby tenant to a primary tenant.
  - The sys tenant of the cluster where the standby tenant resides switches the standby tenant to a primary tenant
```
ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = tenant_name;
```
    Example:
```
obclient> ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = standby1;
```
  - The standby tenant switches itself to a primary tenant
```
obclient> ALTER SYSTEM SWITCHOVER TO PRIMARY;
```
3. Query the DBA_OB_TENANTS view to confirm whether the standby tenant has been switched to a primary tenant.
  - The sys tenant of the cluster where the standby tenant resides queries the view
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
```
  - The standby tenant queries the view
    
    MySQL-compatible tenant:
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
```
    In Oracle-compatible tenant:
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM SYS.DBA_OB_TENANTS;
```
  A sample query result is as follows:
```
+-----------------+-------------+-------------+-------------------+
| TENANT_NAME     | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
+-----------------+-------------+-------------+-------------------+
| standby1        | USER        | PRIMARY     | NORMAL            |
+-----------------+-------------+-------------+-------------------+
1 row in set
```
  Based on the query result, the TENANT_ROLE of the original standby tenant has changed to PRIMARY and SWITCHOVER_STATUS has changed to NORMAL, which indicates that the standby-to-primary switchover is successful.
Set the log restore source for the original primary tenant.

You can configure a log restore source before or after the switchover.
1. Log in to the sys tenant of the original primary tenant or the original primary tenant cluster as the administrator.
2. Execute the following command to set the log restore source.
  - The sys tenant of the cluster where the original primary tenant resides sets the 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;
```
  - The original primary tenant sets the log restore source for itself
```
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 addresses and SQL port number of the OBServer nodes where replicas of the new primary tenant reside. You do not need to specify all OBServer nodes if multiple nodes exist.
  - $user_name: the dedicated user created in the new primary tenant for accessing system views.
  - $tenant_name: the tenant name of the new primary tenant.
  - $password: the password of the dedicated user for accessing 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 about how to set the log restore source, see Set a log restore source.
3. After the configuration succeeds, query the DBA_OB_TENANTS view to confirm whether the original primary tenant is in continuous log synchronization mode.
  
  After you set the log restore source, because the primary tenant has been switched to a standby tenant and continuous log synchronization is automatically enabled, no special processing is required. You can query the DBA_OB_TENANTS view to confirm.
  - The sys tenant of the cluster where the original primary tenant resides queries the view
```
# Query the tenant ID. A tenant ID that is even indicates a user tenant.
obclient> SELECT TENANT_ID, SYNC_SCN FROM oceanbase.DBA_OB_TENANTS;
# Query information based on the user tenant ID.
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;
```
  - The original primary tenant queries the view
    
    MySQL-compatible tenant:
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS, SCN_TO_TIMESTAMP(SYNC_SCN), RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;
```
    In Oracle-compatible tenant:
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS, SCN_TO_TIMESTAMP(SYNC_SCN), RECOVERY_UNTIL_SCN FROM SYS.DBA_OB_TENANTS;
```
  A sample query result in MySQL-compatible tenant 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
```
  Based on the query result, if the value of the RECOVERY_UNTIL_SCN column equals the MAX SCN (4611686018427387903), the original primary tenant is in continuous log synchronization mode. Otherwise, it is not.

Physical standby database based on log archiving

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

Notice

Before performing a switchover, you must first switch the primary tenant to a standby tenant. Otherwise, a problem may occur. For example, two primary tenants may exist at the same time or the standby tenant cannot synchronize logs. In this scenario, the standby tenant does not perceive the status of the original primary tenant. If you switch the standby tenant to a primary tenant in advance, the ALTER SYSTEM SWITCHOVER TO PRIMARY statement may still be executed without errors.

The switchover execution flow in a physical standby database scenario based on log archiving is shown in the following figure.

Switchover procedure

Enable log archiving mode for the standby tenant.

In a physical standby database with log archiving, the original primary tenant needs to synchronize all modifications from the new primary tenant (the original standby tenant) by continuously reading the standby tenant's archived logs. Therefore, the new primary tenant (the original standby tenant) must be in log archiving mode. Additionally, to ensure log continuity, the new primary tenant (the original standby tenant) must enable log archiving before the switchover.
1. Log in to the sys tenant of the standby tenant or the cluster in which the standby tenant is located.
2. Configure the destination of the standby tenant's log archiving.
  
  Notice
  
  When configuring the archive destination, different tenants must use different archive paths.
  
  Configuring the archive destination mainly involves setting the LOCATION, PIECE_SWITCH_INTERVAL, and BINDING attributes.
  - The sys tenant of the cluster where the standby tenant resides configures the archive destination for the standby tenant
```
ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=archive_path [PIECE_SWITCH_INTERVAL=piece_switch_interval] [BINDING=archive_mode]' TENANT = tenant_name;
```
  - The standby tenant configures the archive destination for itself
```
ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=archive_path [PIECE_SWITCH_INTERVAL=piece_switch_interval] [BINDING=archive_mode]';
```
  The parameters are described as follows:
  - LOCATION: specifies the archive destination. Currently, OceanBase Database supports NFS and Alibaba Cloud OSS as archive media.
  - BINDING: specifies the priority mode for archiving and business. Currently, Optional and Mandatory modes are supported. If not configured, the default is Optional.
    - Optional mode prioritizes user business. In this mode, when archiving (log archiving) speed cannot keep up with log generation speed, logs may be recycled before being archived, causing stream interruption.
    - Mandatory mode prioritizes archiving. In this mode, if archiving cannot keep up with user data writes, users may be unable to write.
  - PIECE_SWITCH_INTERVAL configures the piece switch cycle. The value range is [1d, 7d]. If not set, the default is 1d.
  Assuming the archive media is NFS, the following example configures the standby tenant's archive path as file:///data/1/standby2_archive2/ and archive mode as Optional:
```
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 archivelog for the standby tenant.
  - The sys tenant of the cluster where the standby tenant resides enables archivelog for the standby tenant
    
    Example:
```
obclient> ALTER SYSTEM ARCHIVELOG TENANT = standby2;
```
    Here, standby2 is the standby tenant name. Use the actual tenant name in your environment.
  - The standby tenant enables archivelog for itself
```
obclient> ALTER SYSTEM ARCHIVELOG;
```
4. Confirm whether the standby tenant's archiving status is DOING.
  - The sys tenant of the cluster where the standby tenant resides queries the view
```
obclient> SELECT DEST_ID, ROUND_ID, DEST_NO, STATUS, CHECKPOINT_SCN, CHECKPOINT_SCN_DISPLAY, PATH FROM oceanbase.CDB_OB_ARCHIVELOG;
```
  - The standby tenant queries the view
    
    MySQL-compatible tenant:
```
obclient> SELECT DEST_ID, ROUND_ID, DEST_NO, STATUS, CHECKPOINT_SCN, CHECKPOINT_SCN_DISPLAY, PATH FROM oceanbase.DBA_OB_ARCHIVELOG;
```
    Oracle-compatible tenant:
```
obclient> SELECT DEST_ID, ROUND_ID, DEST_NO, STATUS, CHECKPOINT_SCN, CHECKPOINT_SCN_DISPLAY, PATH FROM SYS.DBA_OB_ARCHIVELOG;
```
    A sample query result in MySQL-compatible tenant is as follows:
```
+---------+----------+---------+--------+---------------------+----------------------------+---------------------------------------+
| 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
```
  In the query result, if STATUS is DOING, archiving is in normal operation. CHECKPOINT_SCN and CHECKPOINT_SCN_DISPLAY indicate the current archiving progress.
  
  For more information about how to view the archiving status, see View the archiving progress.
Switch the primary tenant to a 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 resides.
2. Execute the SWITCHOVER TO STANDBY VERIFY command to verify whether the SWITCHOVER command can be executed successfully.
  - The sys tenant of the cluster where the primary tenant resides executes the SWITCHOVER TO STANDBY VERIFY command
```
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT [=] tenant_name VERIFY;
```
    Example:
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql2 VERIFY;
```
  - The primary tenant executes the SWITCHOVER TO STANDBY VERIFY command
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY VERIFY;
```
    If the command returns OK, the verification passes and you can proceed to the next step.
    
    If an error occurs, refer to Switchover or failover issues for handling based on the error message, and then retry the command.
3. After the verification passes, execute the primary-to-standby switchover command to switch the primary tenant to a standby tenant.
  - The sys tenant of the cluster where the primary tenant resides switches the primary tenant to a standby tenant
```
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = tenant_name;
```
    Example:
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql2;
```
  - The primary tenant switches itself to a 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 a standby tenant.
  - The sys tenant of the cluster where the primary tenant resides queries the view
```
obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM oceanbase.DBA_OB_TENANTS 
WHERE TENANT_NAME='mysql2';
```
  - The primary tenant queries the view
    
    MySQL-compatible tenant:
```
obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM oceanbase.DBA_OB_TENANTS 
WHERE TENANT_NAME='mysql2';
```
    Oracle-compatible tenant:
```
obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM SYS.DBA_OB_TENANTS 
WHERE TENANT_NAME='mysql2';
```
  A sample query result is as follows:
```
+-----------+-------------+-------------+-------------+-------------------+
| 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 primary tenant's TENANT_ROLE has changed to STANDBY and SWITCHOVER_STATUS has changed to NORMAL, which indicates that the primary-to-standby switchover is successful.
5. Query the SYNCHRONIZED field in the V$OB_ARCHIVE_DEST_STATUS view and wait for the primary tenant to complete archiving.
  
  In a physical standby database scenario based on log archiving, the standby tenant must read complete logs from the original primary tenant's log archive before it can be switched to a primary tenant. Because log archiving is asynchronous, after the original primary tenant is switched to a standby tenant, you need to check whether the log archive on the original primary tenant is complete.
  - MySQL-compatible tenant
```
obclient> SELECT * FROM oceanbase.V$OB_ARCHIVE_DEST_STATUS WHERE TENANT_ID = 1004;
```
  - Oracle-compatible tenant
```
obclient> SELECT * FROM SYS.V$OB_ARCHIVE_DEST_STATUS WHERE TENANT_ID = 1004;
```
  The query result in MySQL-compatible tenant is 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
```
  In the query result, if the SYNCHRONIZED field shows YES, the primary tenant has completed archiving.
  
  Notice
  
  Before executing the standby-to-primary switchover, ensure that the SYNCHRONIZED field shows YES. Otherwise, after the standby-to-primary switchover, the new primary tenant's data may be incomplete.
Switch the standby tenant to a primary tenant.
1. Log in to the database as the tenant administrator of the standby tenant or the sys tenant of the cluster where the standby tenant resides.
2. Execute the standby-to-primary switchover command to switch the standby tenant to a primary tenant.
  
  Notice
  
  Before the standby-to-primary switchover command starts, the system checks whether the standby tenant has synchronized all logs from the restore source. Therefore, the execution time of the standby-to-primary switchover command depends on the synchronization progress between the standby tenant and the primary tenant.
  - The sys tenant of the cluster where the standby tenant resides switches the standby tenant to a primary tenant
```
ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = tenant_name;
```
    Example:
```
obclient> ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = standby2;
```
  - The standby tenant switches itself to a primary tenant
```
obclient> ALTER SYSTEM SWITCHOVER TO PRIMARY;
```
3. Query the DBA_OB_TENANTS view to confirm whether the standby tenant has been switched to a primary tenant.
  - The sys tenant of the cluster where the standby tenant resides queries the view
```
obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM oceanbase.DBA_OB_TENANTS 
WHERE TENANT_NAME='standby2';
```
  - The standby tenant queries the view
    
    MySQL-compatible tenant:
```
obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM oceanbase.DBA_OB_TENANTS 
WHERE TENANT_NAME='standby2';
```
    Oracle-compatible tenant:
```
obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM SYS.DBA_OB_TENANTS 
WHERE TENANT_NAME='standby2';
```
  A sample query result is as follows:
```
+-----------+----------------------------+-------------+-------------+-------------------+
| TENANT_ID | TENANT_NAME                | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
+-----------+----------------------------+-------------+-------------+-------------------+
|      1006 | standby2                   | USER        | PRIMARY     | NORMAL            |
+-----------+----------------------------+-------------+-------------+-------------------+
1 row in set
```
  Based on the query result, the standby tenant's TENANT_ROLE has changed to PRIMARY and SWITCHOVER_STATUS is NORMAL, which indicates that the standby-to-primary switchover is successful.
Set the restore source for the new standby tenant (original primary tenant) to receive archive logs from the new primary tenant.

If the original primary tenant did not set a log restore source before the switchover, its log synchronization point will remain at the time of the switchover. Therefore, you need to set a log restore source for the original primary tenant, pointing to the new primary tenant.

You can set the log restore source before or after the primary-to-standby switchover.
1. Log in to the database as the tenant administrator of the new standby tenant (original primary tenant) or the sys tenant of the cluster where the new standby tenant resides.
2. Execute the following command to configure the restore source for the new standby tenant (original primary tenant).
  - The sys tenant of the cluster where the new standby tenant resides sets the restore source for the new standby tenant
```
ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=archive_path' TENANT = tenant_name;
```
  - The new standby tenant sets the restore source for itself
```
ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=archive_path';
```
  Here, the LOCATION attribute specifies the archive destination of the new primary tenant.
  
  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. After the configuration succeeds, query the DBA_OB_TENANTS view to confirm whether the original primary tenant is in continuous log synchronization mode.
  
  After you set the log restore source, because the primary tenant has been switched to a standby tenant and continuous log synchronization is automatically enabled, no special processing is required. You can query the DBA_OB_TENANTS view to confirm.
  - The sys tenant of the cluster where the original primary tenant resides queries the view
```
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 primary tenant queries the view
    
    MySQL-compatible tenant:
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS, SCN_TO_TIMESTAMP(SYNC_SCN), RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;
```
    Oracle-compatible tenant:
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS, SCN_TO_TIMESTAMP(SYNC_SCN), RECOVERY_UNTIL_SCN FROM SYS.DBA_OB_TENANTS;
```
  A sample query result in MySQL-compatible tenant 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 of the RECOVERY_UNTIL_SCN column equals the MAX SCN (4611686018427387903), the original primary tenant is in continuous log synchronization mode. Otherwise, it is not.