OceanBase 主备租户

1. 租户级主备库

  在 OceanBase 数据库的容灾体系中，物理备库扮演着“准实时热备份”的关键角色。可以在当主库不可用时接管服务，最大限度降低服务停机时间，减少可能带来的数据损失。

1.1 架构演进

V4.1.0 版本开始， 物理备库的产品形态从集群级变更为租户级：

• V 4.1.0 之前：主备库形态为 集群级，粒度较粗。
• V 4.1.0 及以后：产品形态重构为 租户级。
• 主/备角色信息下沉绑定至 租户，分为 主租户（ Primary Tenant） 和 备租户（ Standby Tenant）。
• 主租户：用户创建的业务租户，提供完整、双向的数据库读写服务能力。
• 备租户：仅提供容灾备用和 只读服务能力。
• 高可用方案：一个主租户与若干个备租户组合，构成灵活的租户级高可用与多活容灾体系。

1.2 核心原理

  物理备库主要通过日志传输服务和日志存储服务来完成日志的传输及存储，并通过日志回放服务来保证主备租户数据的一致。其中：

• 日志传输服务：
• 作用：在主租户和备租户之间实时或准实时同步 Redo 日志。
• 传输模式： OceanBase 物理备库仅提供 异步同步模式。
• 传输路径：支持通过 网络直连或 日志归档传输。
• 日志存储服务：
• 作用：为物理备库提供高可用、高可靠的日志持久化存储与读写能力。
• 日志回放服务：
• 作用：备租户读取写入日志存储服务的日志， 实时或延迟（延迟备库，可以挽回误操作的损失） 地将其应用到内存的 MemStore 中，保障主租户与备租户的数据最终完全一致。

传统数据库是主库主动发日志给备库，而   OceanBase 主租户不感知备租户的存在，也就是主租户不主动往外发日志，而是备租户主动找主租户拉取日志。

1.3 主备库架构部署方案

  一个主租户和对应的备租户可以部署在不同的集群中，也可以部署在同一个 OceanBase 集群中。相应的，同一个 OceanBase 集群中既可以包含主租户，也可以包含备租户，也可以同时包含主备租户。

1.4 备租户限制

• 备租户个数、资源规格（生产环境建议同构）、租户名都不要求与主租户相同。一个主租户可配置多个备租户。
• 配置项：主租户与备租户的配置项相互独立，不会物理同步。在对主库做参数调优时，需手动同步修改备库，避免主备切换后参数失效。
• 系统变量：主租户和备租户的系统变量物理同步，如果在主租户上修改了系统变量，系统会同步修改备租户的相同系统变量。
• 用户及密码：仅支持在主租户上创建用户和修改用户密码，更新后信息同步给备租户。
• 读写操作：备租户支持读操作，不支持写操作。
• 转储与合并：主租户和备租户的转储相对独立。备租户从主租户同步合并信息，不支持独立合并。

2. 日志归档 VS 网络直连

  物理备库通过日志传输服务在主租户和备租户之间实时同步 Redo 日志。备租户既可以从主租户同步日志，也可以从另外一个备租户同步日志（级联同步）。

OceanBase 主备租户之间靠 日志传输服务 同步 Redo 日志，备库拉日志有两种模式：

• 日志归档：主租户先开启 ARCHIVELOG 模式，把 Redo 日志异步归档到 共享存储（OSS/NFS/COS 等）。备租户 不直接连主库，只去归档介质里读 Log Group 回放。类比 Oracle Far Sync；主备之间 不需要网络互通，只要求备库能访问同一个目录，备库与上游租户没有任何直接交互。

• 延迟：秒级~分钟级（默认约 2 分钟刷一次 Piece），但 不依赖主备专线质量，性能和可用性受限于归档存储介质；
• 代价：多一份对象存储费用，主库必须开归档，备库 Switchover 前也要开归档。
• 网络直连：备租户直接通过 网络连接主租户或其他备租户读取日志，类似 于 MySQL 数据库的 Replication。

• 在该部署模式下，备租户和主租户的网络需要联通。
• 备租户直接通过网络连接上游租户的服务节点读取日志。
• 备租户从主租户读取的日志，既可以是主租户的在线日志，也可以是主租户的归档日志，两种日志来源支持自动切换。

3. 创建备租户

3.1 创建空的备租户

创建空的备租户是指仅依靠主租户的日志流来初始化备租户，完全不依赖基线数据或转储文件。

• 限制条件：仅适用于以下两种场景：

1. 主租户刚新建，尚未产生海量历史数据。
2. 主租户所在的集群或日志归档介质上，完好保存了该主租户 自创建以来的全量历史日志。

1. 步骤 1：创建同步专用用户

备租户在拉取日志和校验状态时，需要访问主租户的部分系统视图，因此必须拥有 具备查询权限的只读账号。

• 使用 OCP 云平台创建备租户时，OCP 会自动在主租户中创建 STANDYRO 用户。
• 手动创建备租户时，需要手动创建相应的用户并授予权限：

1. 步骤 2：创建备租户

CREATE STANDBY TENANT standby_tenant_name
LOG_RESTORE_SOURCE = 'SERVICE=ip_list USER=username@tenant_name PASSWORD=password'
RESOURCE_POOL_LIST=('pool_for_standby')
LOCALITY [=] 'locality_description'
PRIMARY_ZONE [=] primary_zone_name;

• LOG_RESTORE_SOURCE：备租户的日志恢复源，指定网络直连模式的相关信息。

SERVICE：主租户所在的一个或多个 OBServer 节点的 IP 地址与 SQL 端口（默认 2881），如 10.xxx.xxx.1:2881;10.xxx.xxx.2:2881。

• USER / PASSWORD：访问主租户视图的用户名与密码。
• RESOURCE_POOL_LIST：指定备租户所使用的资源池。
• LOCALITY / PRIMARY_ZONE：定义备租户副本的分布位置与 Primary Zone 偏好。

3.2 从物理备份 Restore 一个备租户

  使用最广的是 通过备份恢复功能创建备租户的方式，该方式先从数据备份集恢复出基线数据，再从日志归档重放日志，最后开启持续同步。

• 数据源兼容性：数据备份和日志归档既可以来自 主租户，也可以来自 另一个已存在的备租户。
• 主要优势：通用性强，不受主库内存和在线 Clog 保存时间的限制，可用于大规模生产数据的备库建设或跨集群灾备重建。

1. RESTORE 租户：从源租户的物理备份恢复出一个备租户。

语句就是执行恢复的命令，备份恢复的文章中提到过了。

ALTER SYSTEM RESTORE dest_tenant_name FROM uri [ UNTIL {TIME='timestamp' | SCN=scn} ] 
WITH 'pool_list=pool_name[&locality=locality][&primary_zone=zone_name][&concurrency=int_num]';
-- 系统租户执行恢复，指定备份路径和日志归档路径，并指定资源池
ALTER SYSTEM RESTORE mysql FROM 'file:///data/obbackup/data,file:///data/obbackup/archive' WITH 'pool_list=p1&primary_zone=zone1';

1. RECOVER 租户： RESTORE 命令创建的备租户，默认不会与源租户持续同步，需要执行 RECOVER 命令开启持续同步模式。在目标集群中开启备租户的日志同步：

ALTER SYSTEM RECOVER STANDBY TENANT = mysql_back UNTIL UNLIMITED;

• 一个完整的创建备租户并配置数据同步的示例：

-- 1. 在主租户 obmysql 中创建只读同步用户，并授权
obclient -h192.168.182.22 -P2881 -uroot@obmysql -p'OBexampas123%^&'  -c -A -Doceanbase 
CREATE user rep_user identified by 'rep_user';
GRANT SELECT ON *.* TO rep_user;
-- 2. 查询主租户的 IP 列表：
SELECT * FROM DBA_OB_ACCESS_POINT;
+-----------+-------------+----------------+----------+
| TENANT_ID | TENANT_NAME | SVR_IP         | SQL_PORT |
+-----------+-------------+----------------+----------+
|      1002 | obmysql     | 192.168.182.21 |     2881 |
|      1002 | obmysql     | 192.168.182.22 |     2881 |
|      1002 | obmysql     | 192.168.182.23 |     2881 |
+-----------+-------------+----------------+----------+
-- 3. root 用户登录 sys 租户 创建备租户 mysql_back
obclient -h192.168.182.22 -P2881 -uroot@sys -p'OBexampas123%^&'  -c -A -Doceanbase 
obclient [oceanbase]> CREATE RESOURCE UNIT unit1 MAX_CPU 2, MEMORY_SIZE='2G';
Query OK, 0 rows affected (0.021 sec)
obclient [oceanbase]> CREATE RESOURCE POOL pool1 UNIT='unit1',UNIT_NUM=1,ZONE_LIST=('zone1','zone2','zone3');
Query OK, 0 rows affected (0.090 sec)
obclient [oceanbase]> CREATE STANDBY TENANT mysql_back LOG_RESTORE_SOURCE = 'SERVICE=192.168.182.21:2881;192.168.182.22:2881;192.168.182.23:2881 USER=rep_user@obmysql PASSWORD=rep_user'
    -> RESOURCE_POOL_LIST=('pool1');
Query OK, 0 rows affected (1 min 27.861 sec)
-- 4. 查询租户，状态为 normal
SELECT tenant_id, tenant_name, tenant_type, status 
FROM oceanbase.DBA_OB_TENANTS 
WHERE tenant_name = 'mysql_back';
+-----------+-------------+-------------+--------+
| tenant_id | tenant_name | tenant_type | status |
+-----------+-------------+-------------+--------+
|      1008 | mysql_back  | USER        | NORMAL |
+-----------+-------------+-------------+--------+
-- 5. 设置同步
ALTER SYSTEM RECOVER STANDBY TENANT = mysql_back UNTIL UNLIMITED;
-- 6. 测试同步效果
obclient -h192.168.182.22 -P2881 -uroot@obmysql -p'OBexampas123%^&'  -c -A -Doceanbase
obclient [oceanbase]> use lab4spm;
Database changed
obclient [lab4spm]> select * from tb1;
Empty set (0.160 sec)
obclient [lab4spm]> insert into tb1 values(1,1,'aa','aaa');
Query OK, 1 row affected (0.403 sec)
obclient -h192.168.182.22 -P2881 -uroot@mysql_back -p'OBexampas123%^&'  -c -A -Dlab4spm
obclient [lab4spm]> select * from tb1;
+------+------+------+------+
| c1   | c2   | c3   | c4   |
+------+------+------+------+
|    1 |    1 | a    | a    |
+------+------+------+------+

3.3 修改日志恢复源

  无论是基于 日志归档还是 网络直连的物理备库，都支持 在线动态修改日志恢复源，且支持在两种传输模式之间自由切换。

典型场景：

1. 模式切换：主备机房网络维护时，将网络直连模式临时切换为日志归档模式；维护结束后切回网络直连。
2. 主库节点变更：主库扩展或替换节点后，更新网络直连模式中的 ip_list 节点列表。
3. 归档路径变更：主库归档存储迁移（如从 NFS 切换到 OSS 对象存储）后更新路径。

ALTER SYSTEM SET LOG_RESTORE_SOURCE = 
  '{ SERVICE=$ip_list USER=$user_name@$tenant_name PASSWORD=$password | LOCATION=$archive_path }' 
  [TENANT = $tenant_name];

参数与作用域说明：

• SERVICE 模式（网络直连）：
• 指定主库节点 IP 与端口（如 SERVICE=192.168.1.1:2881;192.168.1.2:2881，多 IP 间用分号分隔）及只读鉴权账号。
• LOCATION 模式（日志归档）：
• 指定源租户的日志归档路径（如 LOCATION=file:///data/1/sh_archive 或 LOCATION=oss://bucket/path）。
• TENANT 作用域：
• 在 sys 租户 下执行时：必须显式指定 TENANT = standby_tenant_name。
• 在普通用户租户（备租户自身）下执行时： 无需指定 TENANT 关键字。

--查看同步模式
obclient -h192.168.182.22 -P2881 -uroot@sys -p'OBexampas123%^&'  -c -A -Doceanbase 
obclient [oceanbase]>  SELECT TENANT_ID,ID,TYPE,VALUE,RECOVERY_UNTIL_SCN FROM CDB_OB_LOG_RESTORE_SOURCE\G
*************************** 1. row ***************************
         TENANT_ID: 1004
                ID: 1
              TYPE: LOCATION
             VALUE: file:///data/obbackup/archive
RECOVERY_UNTIL_SCN: 4611686018427387903
*************************** 2. row ***************************
         TENANT_ID: 1008
                ID: 1
              TYPE: SERVICE
             VALUE: IP_LIST=192.168.182.21:2881;192.168.182.22:2881;192.168.182.23:2881,USER=rep_user@obmysql,PASSWORD=9B5ABB882C07295A3DD82E60DDC8B5800540836B2FDEA27570A351014A0DB7F7,TENANT_ID=1002,CLUSTER_ID=1788407972,COMPATIBILITY_MODE=MYSQL,IS_ENCRYPTED=true
RECOVERY_UNTIL_SCN: 4611686018427387903
-- 修改 mysql_back 备租户的日志恢复源
obclient [oceanbase]> ALTER SYSTEM SET LOG_RESTORE_SOURCE='LOCATION=file:///data/obbackup/archive' TENANT = mysql_back;
Query OK, 0 rows affected (0.182 sec)
obclient [oceanbase]>  SELECT * FROM CDB_OB_LOG_RESTORE_SOURCE\G
*************************** 1. row ***************************
         TENANT_ID: 1004
                ID: 1
              TYPE: LOCATION
             VALUE: file:///data/obbackup/archive
RECOVERY_UNTIL_SCN: 4611686018427387903
*************************** 2. row ***************************
         TENANT_ID: 1008
                ID: 1
              TYPE: LOCATION
             VALUE: file:///data/obbackup/archive
RECOVERY_UNTIL_SCN: 4611686018427387903
-- 查看主备租户同步延迟
SELECT 
  t.TENANT_NAME,
  t.TENANT_ROLE,
  t.SYNC_SCN,
  SCN_TO_TIMESTAMP(t.SYNC_SCN) AS sync_time,
  CASE 
    WHEN t.TENANT_ROLE = 'STANDBY' THEN
      ROUND(
        TIMESTAMPDIFF(
          MICROSECOND, 
          SCN_TO_TIMESTAMP(t.SYNC_SCN), 
          SCN_TO_TIMESTAMP((SELECT SYNC_SCN FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'obmysql'))
        ) / 1000.0, 
        2
      )
    ELSE 0.00 
  END AS delay_ms
FROM oceanbase.DBA_OB_TENANTS t
WHERE t.TENANT_NAME IN ('obmysql', 'mysql_back')
ORDER BY t.TENANT_ROLE DESC;
+-------------+-------------+---------------------+----------------------------+-----------+
| TENANT_NAME | TENANT_ROLE | SYNC_SCN            | sync_time                  | delay_ms  |
+-------------+-------------+---------------------+----------------------------+-----------+
| mysql_back  | STANDBY     | 1788771235729981528 | 2026-09-07 16:53:55.729981 | 108088.64 |
| obmysql     | PRIMARY     | 1788771343818622551 | 2026-09-07 16:55:43.818622 |      0.00 |
+-------------+-------------+---------------------+----------------------------+-----------+
-- 再次修改回来，改成基于网络同步，延迟一下子降下来了
obclient [oceanbase]> ALTER SYSTEM SET LOG_RESTORE_SOURCE = 'SERVICE=192.168.182.21:2881;192.168.182.22:2881;192.168.182.23:2881 USER=rep_user@obmysql PASSWORD=rep_user' TENANT = mysql_back;
Query OK, 0 rows affected (1.446 sec)
obclient [oceanbase]> SELECT 
    ->   t.TENANT_NAME,
    ->   t.TENANT_ROLE,
    ->   t.SYNC_SCN,
    ->   SCN_TO_TIMESTAMP(t.SYNC_SCN) AS sync_time,
    ->   CASE 
    ->     WHEN t.TENANT_ROLE = 'STANDBY' THEN
    ->       ROUND(
    ->         TIMESTAMPDIFF(
    ->           MICROSECOND, 
    ->           SCN_TO_TIMESTAMP(t.SYNC_SCN), 
    ->           SCN_TO_TIMESTAMP((SELECT SYNC_SCN FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'obmysql'))
    ->         ) / 1000.0, 
    ->         2
    ->       )
    ->     ELSE 0.00 
    ->   END AS delay_ms
    -> FROM oceanbase.DBA_OB_TENANTS t
    -> WHERE t.TENANT_NAME IN ('obmysql', 'mysql_back')
    -> ORDER BY t.TENANT_ROLE DESC;
+-------------+-------------+---------------------+----------------------------+----------+
| TENANT_NAME | TENANT_ROLE | SYNC_SCN            | sync_time                  | delay_ms |
+-------------+-------------+---------------------+----------------------------+----------+
| mysql_back  | STANDBY     | 1788771973227049546 | 2026-09-07 17:06:13.227049 | -1324.30 |
| obmysql     | PRIMARY     | 1788771971902750369 | 2026-09-07 17:06:11.902750 |     0.00 |
+-------------+-------------+---------------------+----------------------------+----------+

4. 主备租户切换

   OceanBase 支持通过 SWITCHOVER（ 计划内无损切换） 和 FAILOVER（ 故障强制接管） 两种机制改变主备租户角色，用以应对日常运维演练与突发灾难恢复场景。

• SWITCHOVER：用户计划内的角色交换。 SWITCHOVER 操作后：
• 主租户会与对应的备租户会交换租户角色， 维持主备链路，继续保持日志同步；
• 整个过程数据不丢失，RPO = 0；
• 执行时间一般为秒级。

• FAILOVER：主租户遭遇不可逆硬件故障或机房灾难时所做切换。FAILOVER 操作后：
• 备库强制截断日志（按最小同步位点对齐）并升为主库。 主备关系解耦，原主库无法继续直接作为备库。
• 会产生百毫秒级别的数据损失；
• 执行时间一般为秒级。

4.1 SWITCHOVER 实施指南

4.1.1 基于网络直连的 SWITCHOVER

  刚刚配置好的主备租户： obmysql 是主， mysql_back 是备。我们登录 sys 租户进行切换测试一下：

• 步骤 1：将主租户切换为备租户：

1、 预检查（VERIFY）：验证主备状态与网络同步是否正常。

obclient -h192.168.182.22 -P2881 -uroot@sys -p'OBexampas123%^&'  -c -A -Doceanbase 
obclient [oceanbase]> ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = obmysql VERIFY;
Query OK, 0 rows affected (0.082 sec)

SWITCHOVER 要求主库与备库状态正常，主备库之间同步状态正常。

2、验证通过后，将主租户 SWITCHOVER 为备租户：

obclient [oceanbase]> ALTER SYSTEM SWITCHOVER TO STANDBY  TENANT = obmysql;
Query OK, 0 rows affected (2.874 sec)

3、状态校验：查询 DBA_OB_TENANTS 视图，确认主租户是否已切换为备租户。

SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS 
FROM oceanbase.DBA_OB_TENANTS 
WHERE TENANT_NAME = 'obmysql';
+-------------+-------------+-------------+-------------------+
| TENANT_NAME | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
+-------------+-------------+-------------+-------------------+
| obmysql     | USER        | STANDBY     | NORMAL            |
+-------------+-------------+-------------+-------------------+

确认 TENANT_ROLE 变更为 STANDBY 且 SWITCHOVER_STATUS 恢复为 NORMAL。

• 步骤 2：将备租户切换为主租户，其执行过程与步骤1类似。

1、 预检查（VERIFY）：在目标集群下验证备升主条件。

obclient [oceanbase]> ALTER SYSTEM SWITCHOVER TO PRIMARY  TENANT = mysql_back VERIFY;
Query OK, 0 rows affected (1.622 sec)

2、将备租户 SWITCHOVER 为主租户：

obclient [oceanbase]> ALTER SYSTEM SWITCHOVER TO PRIMARY  TENANT = mysql_back;
Query OK, 0 rows affected (1.519 sec)

3、状态校验：查询 DBA OBTENANTS 视图，确认备租户是否已切换为主租户。

SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS 
FROM oceanbase.DBA_OB_TENANTS 
WHERE TENANT_NAME = 'mysql_back';
+-------------+-------------+-------------+-------------------+
| TENANT_NAME | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
+-------------+-------------+-------------+-------------------+
| mysql_back  | USER        | PRIMARY     | NORMAL            |
+-------------+-------------+-------------+-------------------+

确认 TENANT_ROLE 变更为 PRIMARY 且 SWITCHOVER_STATUS 恢复为 NORMAL。

• 步骤 3：设置当前的备租户（ obmysql）的日志恢复源为当前的主租户（ mysql_back）。

obclient [oceanbase]> ALTER SYSTEM SET LOG_RESTORE_SOURCE = 'SERVICE=192.168.182.21:2881;192.168.182.22:2881;192.168.182.23:2881 USER=rep_user@mysql_back PASSWORD=rep_user' TENANT = obmysql;
Query OK, 0 rows affected (0.960 sec)
-- 查询同步延时
SELECT 
  t.TENANT_NAME,
  t.TENANT_ROLE,
  t.SYNC_SCN,
  SCN_TO_TIMESTAMP(t.SYNC_SCN) AS sync_time,
  CASE 
    WHEN t.TENANT_ROLE = 'STANDBY' THEN
      ROUND(
        TIMESTAMPDIFF(
          MICROSECOND, 
          SCN_TO_TIMESTAMP(t.SYNC_SCN), 
          SCN_TO_TIMESTAMP((SELECT SYNC_SCN FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'obmysql'))
        ) / 1000.0, 
        2
      )
    ELSE 0.00 
  END AS delay_ms
FROM oceanbase.DBA_OB_TENANTS t
WHERE t.TENANT_NAME IN ('obmysql', 'mysql_back')
ORDER BY t.TENANT_ROLE DESC;
+-------------+-------------+---------------------+----------------------------+----------+
| TENANT_NAME | TENANT_ROLE | SYNC_SCN            | sync_time                  | delay_ms |
+-------------+-------------+---------------------+----------------------------+----------+
| obmysql     | STANDBY     | 1788777486930797436 | 2026-09-07 18:38:06.930797 |   -92.44 |
| mysql_back  | PRIMARY     | 1788777485820877515 | 2026-09-07 18:38:05.820877 |     0.00 |
+-------------+-------------+---------------------+----------------------------+----------+
2 rows in set (0.230 sec)

注意：执行 SWITCHOVER 操作时，必须先将主租户切换为备租户，再将备租户切换为主租户，以避免出现双主租户的问题。

4.1.2 基于归档的物理备库 SWITCHOVER

  在基于日志归档的物理备库场景中， SWITCHOVER 操作前需要先在备租户中开启日志归档。

• 步骤 1：备租户开启日志归档模式。
• 在基于日志归档的物理备库场景中， SWITHOVER 操作执行成功后，由于原主租户后续需要通过持续读取新主租户（原备租户） 的归档日志来同步新主租户（原备租户）上的所有修改操作，因此，要求新主租户（原备租户）开启日志归档模式。
• 步骤 2：将主租户切换为备租户。 具体操作与基于网络的物理备库的 SWITCHOVER 操作相同。
• 步骤 3：将备租户切换为主租户。 具体操作与基于网络的物理备库的 SWITCHOVER 操作相同。
• 步骤 4：设置当前备租户的日志恢复源为当前主租户的日志归档。

ALTER SYSTEM SET LOG_RESTORE_SOURCE = 'LOCATION=file:///data/obbackup/archive' TENANT = new_standby_tenant;

4.2 FAILOVER

  当主租户发生致命故障（集群宕机、数据损坏或机房失联）且短期内无法恢复时，需要 在备库强行激活（ ACTIVATE）接管业务。 FAILOVER 完成后需要整个租户达到数据一致的状态，因此 FAILOVER 操作会将租户统一恢复到所有日志流的最小同步位点，也意味着 FAILOVER 不能保证数据零丢失。

将备租户 FAILOVER 为主租户的步骤如下：

• 步骤一：验证备库状态及日志回放完成度。该预检查 不会检测主租户状态，仅确认备库本身具备升级条件：

ALTER SYSTEM ACTIVATE STANDBY [TENANT = tenant_name] VERIFY;

• 步骤二：强制激活备租户为主租户( ACTIVE)

ALTER SYSTEM ACTIVATE STANDBY [TENANT = tenant_name];

执行激活命令，备库会将所有日志流统一恢复到**最小同步位点，并截断多余日志完成提主。命令同物理备份恢复的解耦。

• 步骤三：确认备租户已成功升级为独立主库

SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS 
FROM oceanbase.DBA_OB_TENANTS 
WHERE TENANT_NAME = 'tenant_name';

  主备租户的 OCP 白屏操作， OBCP 考试中会考到，练习一两遍就会了。最后，提醒一下：

** Switchover：从主租户发起执行日常切换；

Failover：从备租户发起执行容灾切换，因为主库已经故障了。**

  这里是《实战派K8S&DB》，更多干货敬请关注公众号。如果本文对你有所帮助，欢迎点赞、推荐和转发，也欢迎关注后续文章，一起考证、一起学习 Oceanbase 分布式数据库。