Switchover|V4.4.2|OceanBase Database| docs|Distributed Database

Switchover

Last Updated：2026-05-11 07:58:49 Updated

When the primary tenant is available, you can exchange roles between the primary tenant and one standby tenant with no data loss.

This topic provides operation instructions for switchover based on the two deployment modes of the physical standby tenant.

Limitations

You cannot perform switchover for the system tenant (sys); the system tenant always remains PRIMARY.
Before you switch a standby tenant to a primary tenant, every replica of every log stream on that standby must be online; otherwise wait until replicas are permanently offline as required. From the standby tenant you can query DBA_OB_LS; from the sys tenant of the cluster where the standby resides you can query CDB_OB_LS, to verify that log stream replicas 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

In a network-based physical standby deployment, switchover has three main phases: switch the primary tenant to a standby tenant, configure the log restore source for the former primary, then switch the standby tenant to the primary tenant.

Notice

For switchover, you must first switch the primary tenant to a standby tenant, and only then promote the standby to primary. If you promote the standby first, you risk two primary tenants, and ALTER SYSTEM SWITCHOVER TO PRIMARY may fail.

Switch the primary tenant to a standby tenant.
1. Log in as a tenant administrator to the primary tenant, or to the sys tenant of the cluster where the primary tenant resides.
2. Execute the SWITCHOVER TO STANDBY VERIFY statement to check whether the SWITCHOVER statement can be executed.
  - From the sys tenant of the cluster where the primary tenant resides, execute the SWITCHOVER TO STANDBY VERIFY statement.
```
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT [=] tenant_name VERIFY;
```
    Example:
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql VERIFY;
```
  - Log in to the primary tenant and execute the SWITCHOVER TO STANDBY VERIFY statement.
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY VERIFY;
```
    After the preceding statement is executed, if the return value is OK, the verification is passed, and you can proceed to the next step.
    
    If the preceding statement returns an error message, refer to the text prompt in the error message to handle the issue. For more information, see Issues related to switchover or failover.
3. Execute the primary-to-standby switching command to switch the primary tenant to a standby tenant.
  - From the sys tenant of the cluster where the primary tenant resides, execute the statement to switch the primary tenant to a standby tenant.
```
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = tenant_name;
```
    Example:
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql;
```
  - Log in to the primary tenant and execute the statement to switch the primary tenant 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.
  - From the sys tenant of the cluster where the primary tenant resides, run the query.
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
```
  - Query the view by logging in to the primary tenant.
    
    MySQL-compatible mode:
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
```
    Oracle-compatible mode:
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM SYS.DBA_OB_TENANTS;
```
  The sample query result is as follows:
```
+-------------+-------------+-------------+-------------------+
| TENANT_NAME | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
+-------------+-------------+-------------+-------------------+
| mysql       | USER        | STANDBY     | NORMAL            |
+-------------+-------------+-------------+-------------------+
1 row in set
```
  If the value of the TENANT_ROLE column is STANDBY and the value of the SWITCHOVER_STATUS column is NORMAL, the primary tenant is switched to a standby tenant.
Configure the log restore source for the original primary tenant.

Typically, you can configure the log restore source before or after a standby-to-primary switch. However, if you do not want to change the protection mode after the switchover, configure the log restore source for both the primary and standby tenants before you switch the standby tenant to the primary tenant, and ensure that the log restore source of the primary tenant points to the standby tenant and vice versa.

Note

Starting from OceanBase Database V4.4.2 BP1, you can specify the protection mode to be the maximum protection mode or the maximum availability mode.
1. Log in as a tenant administrator to the original primary tenant, or to the sys tenant of the cluster where that tenant resides.
2. Execute the following statement to configure the log restore source.
  - From the sys tenant of the cluster where the original primary tenant resides, configure the log restore source for that 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 configure 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';
```
  The parameters are described as follows:
  - $ip_list: the IP addresses and SQL ports of the OBServer nodes in the new primary tenant. If multiple OBServer nodes are involved, you can specify only some of them.
  - $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 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 configure the log restore source, see Configure the log restore source.
3. Query the DBA_OB_TENANTS view to confirm whether the original primary tenant is continuously synchronizing log data.
  
  After the log restore source is configured, log data synchronization is automatically enabled when the primary tenant is switched to a standby tenant. You do not need to perform any special operations. You can query the DBA_OB_TENANTS view to check the synchronization status.
  - From the sys tenant of the cluster where the original primary tenant resides, run the query.
```
# Query the ID of a user tenant. If the ID is an even number, it is a user tenant.
obclient> SELECT TENANT_ID, SYNC_SCN FROM oceanbase.DBA_OB_TENANTS;
# Specify the ID of a user tenant and query the information.
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 view by logging in to the original primary tenant.
    
    MySQL-compatible 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-compatible 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-compatible 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 log data. Otherwise, the original primary tenant is not continuously synchronizing log data.
Switch the standby tenant to the primary tenant.
1. Log in as a tenant administrator to the standby tenant, or to the sys tenant of the cluster where the standby tenant resides.
2. Execute the standby-to-primary switching command to switch the standby tenant to the primary tenant.
  - From the sys tenant of the cluster where the standby tenant resides, execute the statement to switch the standby tenant to the primary tenant.
```
ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = tenant_name;
```
    Example:
```
obclient> ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = standby1;
```
  - Log in to the standby tenant and execute the statement to switch the standby tenant to the 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 the primary tenant.
  - Query the view in the sys tenant of the cluster where the standby tenant resides.
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
```
  - Query the view of the standby tenant.
    
    In MySQL-compatible mode:
```
obclient> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
```
    In Oracle-compatible 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 changed to PRIMARY and the SWITCHOVER_STATUS is changed to NORMAL, the standby tenant has been successfully switched to the primary tenant.

Log archiving-based physical standby

For a log archiving-based physical standby deployment, switchover has three main phases: enable log archiving on the standby tenant --> switch the primary tenant to a standby tenant --> switch the standby tenant to the primary tenant.

Notice

For switchover, you must first switch the primary tenant to a standby tenant. Otherwise you may end up with two primaries, or the standby may be unable to finish log synchronization. In this deployment model the standby cannot see the primary's state, so if you promote the standby first, ALTER SYSTEM SWITCHOVER TO PRIMARY may still succeed without an error—making the problem harder to detect.

Enable the archive mode for the standby tenant.

In this process, the new primary tenant (original standby tenant) must be set to archive mode so that it can provide the original primary tenant with archiving logs for synchronization of the modifications that occurred on the new primary tenant. Moreover, before the switchover operation, the new primary tenant (original standby tenant) must be set to archive mode to ensure the continuity of logs after switchover.
1. Log in as an administrator to the standby tenant, or to the sys tenant of the cluster where the standby tenant resides.
2. Configure the archiving destination for the standby tenant.
  
  Notice
  
  When you configure an archiving destination, you must use different paths for tenants.
  
  The main purpose of setting the archiving destination is to configure the LOCATION, PIECE_SWITCH_INTERVAL, and BINDING attributes.
  - Set the archiving destination for 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;
```
  - Set the archiving destination for the standby tenant.
```
ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=archive_path [PIECE_SWITCH_INTERVAL=piece_switch_interval] [BINDING=archive_mode]';
```
  The attributes are described as follows:
  - LOCATION: specifies the archiving destination. OceanBase Database supports the NFS and Aliyun OSS media types.
  - BINDING: specifies the priority between business operations and archiving. Currently, only the Optional and Mandatory modes are supported. If not specified, the default value is Optional.
    - In the Optional mode, business operations take precedence. If logs cannot be archived because of the low archiving speed, the system may recycle them and result in a disconnection.
    - In the Mandatory mode, archiving takes precedence. If the archiving speed cannot keep up with the data write speed, data write is blocked.
  - The PIECE_SWITCH_INTERVAL attribute specifies the interval of piece switching, in days. The value ranges from 1d to 7d. If not specified, the default value is 1d.
  The following sample statement sets the archiving destination of the standby tenant to file:///data/1/standby2_archive2/, and specifies the archiving mode as Optional if the archiving media is NFS:
```
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 the archive mode for the standby tenant.
  - Enable the archive mode for the sys tenant of the cluster where the standby tenant is located.
    
    Sample statement:
```
obclient> ALTER SYSTEM ARCHIVELOG TENANT = standby2;
```
    Here, standby2 indicates the name of the standby tenant. Please replace it with the actual name of the tenant in your environment.
  - Enable the archive mode for the standby tenant.
```
obclient> ALTER SYSTEM ARCHIVELOG;
```
4. Check whether the archiving 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 in the standby tenant.
    
    For MySQL-compatible mode:
```
obclient> SELECT DEST_ID, ROUND_ID, DEST_NO, STATUS, CHECKPOINT_SCN, CHECKPOINT_SCN_DISPLAY, PATH FROM oceanbase.DBA_OB_ARCHIVELOG;
```
    For Oracle-compatible mode:
```
obclient> SELECT DEST_ID, ROUND_ID, DEST_NO, STATUS, CHECKPOINT_SCN, CHECKPOINT_SCN_DISPLAY, PATH FROM SYS.DBA_OB_ARCHIVELOG;
```
    In MySQL-compatible mode, the query result is similar to the following sample:
```
+---------+----------+---------+--------+---------------------+----------------------------+---------------------------------------+
| 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 STATUS is DOING, archiving is running normally. CHECKPOINT_SCN and CHECKPOINT_SCN_DISPLAY show the current archiving progress.
  
  For more information about how to check the archiving status, see View the archiving progress.
Switch the primary tenant to the standby tenant.
1. Log in to the database as a 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 check whether the SWITCHOVER statement can be executed successfully.
  - The sys tenant of the cluster where the primary tenant is located executes the SWITCHOVER TO STANDBY VERIFY statement.
```
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT [=] tenant_name VERIFY;
```
    Sample statement:
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql2 VERIFY;
```
  - The primary tenant executes the SWITCHOVER TO STANDBY VERIFY statement.
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY VERIFY;
```
    If OK is returned, the verification is passed and you can proceed to the next step.
    
    For more information about how to handle errors, see Switchover or failover issues.
3. If the verification is passed, execute the primary-to-standby switchover statement to switch the primary tenant to the standby tenant.
  - The sys tenant of the cluster where the primary tenant is located executes the primary-to-standby switchover statement.
```
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = tenant_name;
```
    Sample statement:
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql2;
```
  - The primary tenant executes the primary-to-standby switchover statement.
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY;
```
4. Query the DBA_OB_TENANTS view to check whether the primary tenant has been switched to a standby tenant.
  - The sys tenant of the cluster where the primary tenant is located 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.
    
    For MySQL-compatible mode:
```
obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM oceanbase.DBA_OB_TENANTS 
WHERE TENANT_NAME='mysql2';
```
    For Oracle-compatible mode:
```
obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM SYS.DBA_OB_TENANTS 
WHERE TENANT_NAME='mysql2';
```
  The query result is similar to the following sample:
```
+-----------+-------------+-------------+-------------+-------------------+
| TENANT_ID | TENANT_NAME | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
+-----------+-------------+-------------+-------------+-------------------+
|      1004 | mysql2      | USER        | STANDBY     | NORMAL            |
+-----------+-------------+-------------+-------------+-------------------+
1 row in set
```
  As shown in the query results, the TENANT_ROLE of the primary tenant has changed to STANDBY, and the SWITCHOVER_STATUS has changed to NORMAL, indicating that the primary-to-standby switch was successful.
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 scenario based on log archiving, before a standby tenant is switched to the primary tenant, it needs to read all logs from the log archives of the original primary tenant. Since log archiving operates in asynchronous synchronization mode, after the original primary tenant is switched to a standby tenant, you need to check whether the logs on the original primary tenant are complete.
  - MySQL-compatible mode
```
obclient> SELECT * FROM oceanbase.V$OB_ARCHIVE_DEST_STATUS WHERE TENANT_ID = 1004;
```
  - Oracle-compatible mode
```
obclient> SELECT * FROM SYS.V$OB_ARCHIVE_DEST_STATUS WHERE TENANT_ID = 1004;
```
  The query result in MySQL-compatible mode 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
```
  If the SYNCHRONIZED field shows YES, it indicates that the primary tenant has completed the archiving.
  
  Notice
  
  Before you execute the standby-to-primary switch, make sure that the SYNCHRONIZED field shows YES. Otherwise, after the standby-to-primary switch, the new primary tenant may have incomplete data.
Switch the standby tenant to the primary tenant.
1. Log in to the database as a tenant administrator, using either the standby tenant or the sys tenant of the cluster where the standby tenant resides.
2. Execute the standby-to-primary switch command to switch the standby tenant to the primary tenant.
  
  Notice
  
  Before the standby-to-primary switch command is executed, the system checks whether the standby tenant has synchronized all logs to the restore source. Therefore, the execution time of the standby-to-primary switch command depends on the synchronization progress between the standby and primary tenants.
  - The sys tenant in the cluster where the standby tenant is located switches the standby tenant to the 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 the 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 the primary tenant.
  - The sys tenant in the cluster where the standby tenant is located 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 primary tenant queries the view.
    
    MySQL-compatible mode:
```
obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM oceanbase.DBA_OB_TENANTS 
WHERE TENANT_NAME='standby2'';
```
    Oracle-compatible mode:
```
obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM SYS.DBA_OB_TENANTS 
WHERE TENANT_NAME='standby2'';
```
  The query result is as follows:
```
+-----------+----------------------------+-------------+-------------+-------------------+
| TENANT_ID | TENANT_NAME                | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
+-----------+----------------------------+-------------+-------------+-------------------+
|      1006 | standby2                   | USER        | PRIMARY     | NORMAL            |
+-----------+----------------------------+-------------+-------------+-------------------+
1 row in set
```
  If the TENANT_ROLE of the standby tenant is PRIMARY and the SWITCHOVER_STATUS is NORMAL, the standby-to-primary switch was successful.
Set the restore source of the new standby tenant (original primary tenant) to receive the archived logs of the new primary tenant.

If the original primary tenant has not set a log restore source before the switch, the log synchronization point will remain at the time of the switch. 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-standby switch.
1. Log in to the database as a tenant administrator, using either the new standby tenant (the former primary) or the sys tenant of the cluster where that tenant resides.
2. Execute the following command to set the restore source of the new standby tenant (original primary tenant).
  - The sys tenant in the cluster where the new standby tenant is located sets the restore source of the new standby tenant.
```
ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=archive_path' TENANT = tenant_name;
```
  - The new standby tenant sets its own restore source.
```
ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=archive_path';
```
  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 restore source is set successfully, query the DBA_OB_TENANTS view to confirm whether the original primary tenant is in continuous log synchronization mode.
  
  After the log restore source is set, continuous log synchronization is already enabled automatically because the former primary tenant is already a standby tenant. No special steps are required beyond confirming in DBA_OB_TENANTS.
  - The sys tenant in the cluster where the original primary tenant is located 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 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-compatible 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-compatible mode 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 |
+-------------+-------------+-------------+-------------------+----------------------------+---------------------+
```
  If the value of the RECOVERY_UNTIL_SCN column is equal to the maximum SCN (4611686018427387903), it indicates that the original primary tenant is in continuous log synchronization mode. Otherwise, the original primary tenant is not in continuous log synchronization mode.

OceanBase

Customer Stories

Documentation

Switchover

Limitations

Network-based physical standby

Notice

Note

Log archiving-based physical standby

Notice

Notice

Notice

Notice