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

Switchover

Last Updated：2026-05-07 11:26:25 Updated

When 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 integrity.

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

Limitations

You cannot switch the tenant role of the system tenant (sys) to STANDBY. 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 in the standby tenant must be online. Otherwise, you need to wait for the corresponding replicas to permanently go offline. 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 cluster to check whether all log stream replicas are online. For more information about log stream replicas, see Replica introduction.
You cannot execute the Switchover command in a session that is established by using a service name. For more information about services, see Create a service.

Switch over a tenant to another tenant

In a network-based physical standby tenant scenario, the switch over process generally involves the following three stages: switch the primary tenant to a standby tenant --> switch the standby tenant to the primary tenant --> set the log restore source for the original primary tenant.

Note

Before you switch the roles of the primary and standby tenants, you must switch the primary tenant to a standby tenant, and then switch the standby tenant to the primary tenant. If you switch the standby tenant to the primary tenant before switching the primary tenant to a standby tenant, the ALTER SYSTEM SWITCHOVER TO PRIMARY command might fail because of the presence of two primary tenants.

Switch the primary tenant to a standby tenant.
1. Log in to the sys tenant of the primary tenant or the cluster where the primary tenant resides as the administrator.
2. Execute the SWITCHOVER TO STANDBY VERIFY statement. This verifies whether the SWITCHOVER statement can be executed.
  - The sys tenant of the cluster where the primary tenant resides executes the SWITCHOVER TO STANDBY VERIFY statement
```
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT [=] tenant_name VERIFY;
```
    Example:
```
obclient(root@sys)[(none)]> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql 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 successful. You can proceed to the next step.
    
    If an error is returned, handle the error based on the text provided and then re-execute this statement.
3. Execute the primary-to-standby switch 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(root@sys)[(none)]> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql;
```
  - The primary tenant switches the 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.
  - The sys tenant of the cluster where the primary tenant resides queries the view
```
obclient(root@sys)[(none)]> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
```
  - The primary tenant queries the view
    
    MySQL mode:
```
obclient(root@mysql)[(none)]> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
```
    Oracle mode:
```
obclient(sys@oracle001)[SYS]> 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 value of the TENANT_ROLE column for the original primary tenant is STANDBY and the value of the SWITCHOVER_STATUS column is NORMAL, the primary-to-standby switch is successful.

Switch the standby tenant to the primary tenant.

Log in to the sys tenant of the standby tenant or the cluster where the standby tenant resides as the administrator.
Execute the standby-to-primary switch command to switch the standby tenant to the primary tenant.
- The sys tenant of the cluster where the standby tenant resides switches the standby tenant to the primary tenant
```
ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = tenant_name;
```
  Example:
```
obclient(root@sys)[(none)]> ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = standby1;
```
- The standby tenant switches the tenant to the primary tenant
```
obclient> ALTER SYSTEM SWITCHOVER TO PRIMARY;
```

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

The sys tenant of the cluster where the standby tenant resides queries the view

obclient(root@sys)[(none)]> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;

The standby tenant queries the view

MySQL mode:

obclient(root@standby1)[(none)]> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;

Oracle mode:

obclient(sys@standby1)[SYS]> 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 value of the TENANT_ROLE column for the original standby tenant is PRIMARY and the value of the SWITCHOVER_STATUS column is NORMAL, the standby-to-primary switch is successful.

Set the log restore source for the original primary tenant.

Before or after you perform a primary-to-standby switch or a standby-to-primary switch, you can set the log restore source for the original primary tenant.

Log in to the sys tenant of the original primary tenant or the cluster where the original primary tenant resides as the administrator.
Execute the following statement 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
```
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 in the cluster where the new primary tenant resides. You do not need to specify all of the OBServer nodes.
- $user_name: A dedicated user for accessing the system view.
- $tenant_name: The name of the new primary tenant.
- $password: The password for the dedicated user.
Example:
```
obclient(root@sys)[(none)]> 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 the log restore source.

After the log restore source is set, query the DBA_OB_TENANTS view to check whether the original primary tenant is in continuous log synchronization mode.

After you switch the original primary tenant to a standby tenant, the log continuous synchronization mode will be automatically enabled. You can query the DBA_OB_TENANTS view to confirm this.

The sys tenant of the cluster where the original primary tenant resides queries the view

# Query the user tenant ID. If the ID is an even number, the user tenant is identified.
obclient(root@sys)[(none)]> SELECT TENANT_ID, SYNC_SCN FROM oceanbase.DBA_OB_TENANTS;
# Query information for a specified user tenant.
obclient(root@sysy)[(none)]> 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

In 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;

In 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 in the RECOVERY_UNTIL_SCN column is equal to the maximum SCN (4611686018427387903), the primary tenant is continuously synchronizing logs. Otherwise, the primary tenant is not continuously synchronizing logs.

Physical Standby Database Based on Log Archiving

In the physical standby database scenario based on log archiving, switchover involves the following three phases: enabling the log archiving mode for the standby tenant, switching the primary tenant to the standby tenant, and switching the standby tenant to the primary tenant.

NOTICE

Before initiating a switchover, you must switch the primary tenant to the standby tenant. Otherwise, dual primary tenants may occur, or the standby tenant may fail to synchronize logs. Additionally, in a physical standby database scenario based on log archiving, the standby tenant cannot detect the original primary tenant's status. Therefore, if you switch the standby tenant to the primary tenant first and then execute the ALTER SYSTEM SWITCHOVER TO PRIMARY command, the system will not return an error.

The following figure shows the execution process of Switchover in a physical standby database environment based on log archiving.

Enable archiving mode for the standby tenant.

In a physical standby database scenario based on log archiving, after the Switchover operation is executed successfully, the new primary database (the former standby database) will need to continuously read the archived logs of the new primary database to synchronize all modification operations performed on the new primary database. Therefore, the new primary database must be in log archive mode. To ensure the continuity of logs after the Switchover, the new primary database must enable log archiving before the Switchover operation.
1. Log in to the sys tenant of the standby tenant or the standby cluster as the admin user.
2. Configure the archive destination for the standby tenant.
  
  Note
  
  You must configure different archival paths for different tenants.
  
  Configuring the archiving destination primarily involves setting the LOCATION, PIECE_SWITCH_INTERVAL, and BINDING properties.
  - Configure the destination database for archiving in the sys tenant of the standby cluster for standby tenants.
```
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 this tenant on the standby tenant.
```
ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=archive_path [PIECE_SWITCH_INTERVAL=piece_switch_interval] [BINDING=archive_mode]';
```
  The parameter descriptions are as follows:
  - LOCATION: specifies the target destination where the archive is stored. At present, OceanBase Database supports the Network File System (NFS) and Alibaba Cloud Object Storage Service (OSS) as the targets.
  - BINDING - This parameter specifies the priority mode of the archiving and business processes. The supported values are Optional and Mandatory. The default value is Optional if the parameter is not specified.
    - In the Optional mode, user business takes priority. In this mode, when the archiving speed of logs cannot match the speed of log generation, logs may be recycled before being archived. Then, data transmission is interrupted.
    - Mandatory mode gives priority to archiving. In this mode, if the archive rate is slower than the user data write rate, the user might not be able to write data.
  - The PIECE_SWITCH_INTERVAL attribute is used to configure the switch cycle for a piece, with a range of [1d, 7d]. If not set, the default is 1d.
  For example, if you have set the archival media to NFS, and the archival path for the standby tenant is file:///data/1/standby2_archive2/, and the archival mode is Optional:
```
obclient(root@sys)[(none)]> 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 archive mode for the standby tenant.
  - Enable the archiving mode for the sys tenant in the cluster where the standby tenant resides.
    
    Here is an example:
```
obclient(root@sys)[(none)]> ALTER SYSTEM ARCHIVELOG TENANT = standby2;
```
    where standby2 indicates the name of the standby tenant. Please use the tenant name in your actual environment.
  - Enable the archive mode of the current tenant in the standby tenant.
```
obclient> ALTER SYSTEM ARCHIVELOG;
```
4. Check whether the archive status of the standby tenant is DOING.
  - Query the view of the sys tenant in the cluster where the standby tenant is located.
```
obclient(root@sys)[(none)]> SELECT DEST_ID, ROUND_ID, DEST_NO, STATUS, CHECKPOINT_SCN, CHECKPOINT_SCN_DISPLAY, PATH FROM oceanbase.CDB_OB_ARCHIVELOG;
```
  - Queries in a 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 query results in MySQL mode are 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
```
  Based on the query result, if the value of the STATUS column is DOING, the archiving process is in a normal working state. The values of CHECKPOINT_SCN and CHECKPOINT_SCN_DISPLAY represent the current archiving progress.
  
  For more information, see View the archive progress.
Switch the primary tenant to a secondary tenant.
1. Log in to the database with the account of a tenant administrator in the sys tenant of the main tenant or the cluster where the main tenant is located.
2. Execute the SWITCHOVER TO STANDBY VERIFY command to verify that the SWITCHOVER command can be executed.
  - Execute the SWITCHOVER TO STANDBY VERIFY command for the sys tenant in the primary tenant cluster.
```
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT [=] tenant_name VERIFY;
```
    Example:
```
obclient(root@sys)[(none)]> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql2 VERIFY;
```
  - Execute the SWITCHOVER TO STANDBY VERIFY command in the primary tenant.
```
obclient> ALTER SYSTEM SWITCHOVER TO STANDBY VERIFY;
```
    After you run the command, OK is returned if the verification is passed.
    
    If an error occurs, reference the Switchover or Failover Related Issues document based on the error message provided, and then retry the command.
3. After the validation is successful, execute the "Switchover" command to switchover the primary to the standby tenant.
  - In the cluster to which the primary tenant belongs, set the primary tenant to a standby tenant in the sys tenant.
```
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = tenant_name;
```
    Example:
```
obclient(root@sys)[(none)]> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = mysql2;
```
  - The primary tenant changes the current 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 switched to a standby tenant.
  - sys tenant views in the cluster where the parent tenant resides
```
obclient(root@sys)[(none)]> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM oceanbase.DBA_OB_TENANTS 
WHERE TENANT_NAME='mysql2';
```
  - View for querying 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';
```
    In Oracle mode, your database is in Oracle-compatible mode, which means that the data types and stored procedures supported in the database are similar to those in Oracle Database 12c.
```
obclient> SELECT TENANT_ID, TENANT_NAME,TENANT_TYPE,TENANT_ROLE,SWITCHOVER_STATUS 
FROM SYS.DBA_OB_TENANTS 
WHERE TENANT_NAME='mysql2';
```
  An example of the query results is shown below:
```
+-----------+-------------+-------------+-------------+-------------------+
| TENANT_ID | TENANT_NAME | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
+-----------+-------------+-------------+-------------+-------------------+
|      1004 | mysql2      | USER        | STANDBY     | NORMAL            |
+-----------+-------------+-------------+-------------+-------------------+
1 row in set
```
  The query result shows that the TENANT_ROLE of the original primary tenant has changed to STANDBY, and the SWITCHOVER_STATUS has changed to NORMAL. This 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 original primary tenant to complete archiving.
  
  In a physical standby scenario based on log archiving, the standby tenant needs to read all logs from the log archives of the original primary tenant before it becomes the primary tenant. Since log archiving is asynchronous, after the original primary tenant is switched to a standby tenant, you must check whether the logs 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 result in MySQL 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 original primary tenant has completed archiving.
  
  Notice
  
  Before you execute the standby-to-primary switchover, make sure that the SYNCHRONIZED field shows YES. Otherwise, after you execute the standby-to-primary switchover, the new primary tenant may have incomplete data.

Switch the standby tenant to the primary tenant.

Log in to the database as the tenant administrator of the sys tenant of the standby tenant or the standby tenant's cluster.
Execute the standby-to-primary switchover command to switch the standby tenant to the primary tenant.

Notice

Before you execute the standby-to-primary switchover command, the system checks whether the standby tenant has synchronized all logs to 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 is located switches the standby tenant to the primary tenant.
```
ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = tenant_name;
```
  Example:
```
obclient(root@sys)[(none)]> ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = standby2;
```
- The standby tenant switches itself to the primary tenant.
```
obclient> ALTER SYSTEM SWITCHOVER TO PRIMARY;
```

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

The sys tenant of the cluster where the standby tenant is located queries the view.

obclient(root@sys)[(none)]> 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 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'';

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 original standby tenant has changed to PRIMARY, and the SWITCHOVER_STATUS is NORMAL, the standby-to-primary switchover is successful.

Set the restore source of the new standby tenant (original primary tenant) to receive the archive logs of the new primary tenant.

If the original primary tenant has not set a log restore source before the switchover, the log synchronization point will remain at the time of the switchover. Therefore, you must set the log restore source of the original primary tenant to point to the new primary tenant.

You can execute the log restore source setting operation 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 is located.
2. Execute the following command to configure the restore source of the new standby tenant (original primary tenant).
  - The sys tenant of 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.
  
  The sys tenant of the cluster where the new standby tenant is located sets the restore source of the new standby tenant, as follows:
```
obclient(root@sys)[(none)]> ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=file:///data/1/standby2/archive2' TENANT = mysql2;
```
  The new standby tenant sets its own restore source, as follows:
```
obclient> ALTER SYSTEM SET LOG_RESTORE_SOURCE ='LOCATION=file:///data/1/standby2/archive2';
```
3. After the restore source is set, query the DBA_OB_TENANTS view to confirm whether the original primary tenant is in a continuous log synchronization state.
  
  After the primary tenant is switched to the standby tenant, continuous log synchronization is automatically enabled. Therefore, 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 is located queries the view.
```
obclient(root@sys)[(none)]> 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 mode:
```
obclient(root@mysql2)[(none)]> 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(sys@oracle001)[SYS]> 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  |
+-------------+-------------+-------------+-------------------+----------------------------+---------------------+
| 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 a continuous log synchronization state. Otherwise, the original primary tenant is not in a continuous log synchronization state.

OceanBase

Customer Stories

Documentation

Switchover

Limitations

Switch over a tenant to another tenant

Note

Physical Standby Database Based on Log Archiving

Note

Notice

Notice