--- title: "数据库层高可用 - OceanBase AI 数据库 V4.6.2 | OceanBase 文档中心" description: 数据库层高可用 OceanBase AI 数据库基于高性价比的普通服务器采用 Paxos 协议，同一份数据写到多台（>= 3）日志服务的多副本的半数上，因此当少数派副本不可用（三副本集群允许一个副本不可用）时不会有任何数据丢失，保证 RPO = 0；Leader 副本发生故障后，剩余的 Follower 副本能够在短… image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*w3cwQYKZAJwAAAAAHhAAAAgAeiGDAQ/original) OceanBase AI 数据库V 4.6.2 # 数据库层高可用 更新时间：2026-09-15 10:00:45 [编辑](https://github.com/oceanbase/oceanbase-database-ai/edit/V4.6.2/zh-CN/600.manage/400.high-availability/200.multi-replica-disaster-recovery/300.database-high-availability.md) OceanBase AI 数据库基于高性价比的普通服务器采用 Paxos 协议，同一份数据写到多台（>= 3）日志服务的多副本的半数上，因此当少数派副本不可用（三副本集群允许一个副本不可用）时不会有任何数据丢失，保证 RPO = 0；Leader 副本发生故障后，剩余的 Follower 副本能够在短时间内自动选出新 Leader 继续提供服务，无需外部介入，保证 RTO < 8 秒，从而达到强一致和高可用的平衡。用户也可以采用灵活的部署模式，例如，单机房、同城三中心等，从而达到各级无损容灾能力。 ## Root Service 在 OceanBase AI 数据库中，Root Service 负责集群的节点管理，各 OBServer 通过心跳数据包（heartbeat）的方式，定期（每 2s）向 Root Service 汇报自己的进程状态，Root Service 通过监测 OBServer 的心跳数据包，来获取当前 OBServer 进程的工作状态。 OBServer 心跳状态相关的配置项如下： - `lease_time` 集群级配置项 `lease_time` 用于设置心跳租约时长。该配置项的默认值为 10s。有关该配置项的详细信息，参见 [lease_time](https://www.oceanbase.com/docs/common-oceanbase-database-ai-1000000006781374)。 当 Root Service 累计超过 `lease_time` 时间没有收到过某 OBServer 的任意心跳数据包时，Root Service 认为该 observer 进程短暂断线，Root Service 会标记该 OBServer 服务器的心跳状态为 `lease_expired`。 - `server_permanent_offline_time` 集群级配置项 `server_permanent_offline_time` 用于设置节点心跳中断的时间阈值，即节点心跳中断多久后认为其被永久下线，永久下线的节点上的数据副本需要被自动补足。该配置项的默认值为 3600s。有关该配置项的更多详细信息，参见 [server_permanent_offline_time](https://www.oceanbase.com/docs/common-oceanbase-database-ai-1000000006781364)。 当 Root Service 累计超过 `server_permanent_offline_time` 时间没有收到过某 OBServer 的任意心跳数据包时，Root Service 认为该 observer 进程断线，Root Service 会标记该 OBServer 的心跳状态为 `permanent_offline`。 #### 说明 您可以通过 `SHOW PARAMETERS` 语句查看以上集群级配置项的值，例如，`SHOW PARAMETERS LIKE 'server_permanent_offline_time';`。 Root Service 根据心跳数据包可以获得 OBServer 如下的工作状态： - OBServer 心跳数据包存在，心跳数据包中的 OBServer 磁盘状态正常。此种状态下，Root Service 认为 OBServer 处于正常工作状态。 - OBServer 心跳数据包存在，心跳数据包中的 OBServer 磁盘状态异常。此种状态下，Root Service 认为 observer 进程还在，但 OBServer 磁盘故障。此种状态下，Root Service 会尝试将该 OBServer 上的全部 leader 副本切走。 - OBServer 心跳数据包不存在，OBServer 心跳数据包的丢失时间还比较短，OBServer 心跳状态为 `lease_expired`，此种状态下，Root Service 仅将 OBServer 的工作状态设置为 inactive，不做其他处理。 - OBServer 心跳数据包不存在，OBServer 心跳数据包丢失时间超过 `server_permanent_offline_time`，OBServer 的心跳状态为 `permanent_offline`，此种情况下，Root Service 会对该 OBServer 上的数据副本进行处理，将该 OBServer 上包含的数据副本从 Paxos 成员组中删除，并在其他可用 OBServer 上补充数据，以保证数据副本 Paxos 成员组完整。 ## 隔离节点 ODP 会感知 OBServer 的异常状态，例如 stopped（`ACTIVE` 状态且 `stop_time` 字段大于 0）状态、`INACTIVE` 状态等，从而避免将应用流量路由到异常节点上。 如果某个节点不稳定，可能时不时提供服务，存在响应慢等各种不正常情况。如果客户端连接到该节点，将导致客户端感受到不稳定。OceanBase AI 数据库提供了 `STOP SERVER` 命令用于隔离节点。隔离后，该节点不会对外提供服务，ODP 也不会把请求路由到该节点上，可以安全的进行诊断/替换/维修等动作，是运维和应急的利器。Stop Server 会检查所有剩余副本是否满足多数派、是否日志同步，当条件不满足的时候 Stop Server 操作会返回失败；条件满足的情况下等待故障节点上的 Leader 全部切走后系统会返回成功。Stop Server 成功后保证能够做任何运维动作，包括 Kill observer 进程。Stop Server 的详细操作请参见 [隔离节点](https://www.oceanbase.com/docs/common-oceanbase-database-ai-1000000006858158)。 节点隔离适用于单机房故障场景： - 非通断型故障（例如网卡丢包导致的机器不稳定）强依赖节点隔离，否则会发生反复切主而影响应用。 - 通断型故障（例如机器直接宕机）不强依赖节点隔离，其会在 `oceanbase.DBA_OB_SERVERS` 视图标记节点状态为 `INACTIVE` 而隔离应用流量。 在节点隔离或者 Leader 出现故障时，会触发选举。选举服务的优先级机制会考虑用户指定的 Primary Zone，考虑机器的异常状态等，从而保证选择更优的副本作为主副本。 ## 容灾操作 OceanBase AI 数据库采用存算分离架构，通过高可用日志服务提供数据的持久性，保证数据不丢失（RPO=0），通过多副本计算节点保障数据的高可用。副本数不同，对应的容灾操作也不同：两副本部署支持手动切主，单副本部署支持可用区（AZ）内或跨可用区（AZ）容灾。有关副本部署场景的详细介绍，参见 [容灾部署方案](https://www.oceanbase.com/docs/common-oceanbase-database-ai-1000000006859344)。 #### 说明 单副本跨可用区（AZ）容灾功能从 V4.6.2.1 版本开始支持。 ### 两副本场景容灾操作 对于计算节点两副本部署场景，除了隔离节点，您还可以主动切主，切换日志流副本的主备角色。 主动切主的操作步骤如下： 1. 使用 `root` 用户登录到集群的 `sys` 租户。 连接示例如下，连接数据库时请以实际环境为准。 ```shell obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A ``` 有关更加详细的连接数据库的操作指引，参见 [连接数据库概述](https://www.oceanbase.com/docs/common-oceanbase-database-ai-1000000006779047)。 2. 获取租户的 Zone、Server 及日志流副本信息。 ```shell obcllient [(none)]> SELECT a.TENANT_ID,a.LS_ID,a.SVR_IP,a.SVR_PORT,a.ZONE,a.role,b.TENANT_NAME,b.TENANT_TYPE FROM oceanbase.CDB_OB_LS_LOCATIONS a, oceanbase.DBA_OB_TENANTS b WHERE a.TENANT_ID=b.TENANT_ID; ``` 查询结果如下： ```shell +-----------+-------+----------------+----------+-------+----------+-------------+-------------+ | TENANT_ID | LS_ID | SVR_IP | SVR_PORT | ZONE | role | TENANT_NAME | TENANT_TYPE | +-----------+-------+----------------+----------+-------+----------+-------------+-------------+ | 1 | 1 | xx.xx.xx.237 | 2882 | zone1 | LEADER | sys | SYS | | 1 | 1 | xx.xx.xx.238 | 2882 | zone2 | FOLLOWER | sys | SYS | | 1001 | 1 | xx.xx.xx.237 | 2882 | zone1 | LEADER | META$1002 | META | | 1001 | 1 | xx.xx.xx.238 | 2882 | zone2 | FOLLOWER | META$1002 | META | | 1002 | 1 | xx.xx.xx.237 | 2882 | zone1 | LEADER | mysql001 | USER | | 1002 | 1 | xx.xx.xx.238 | 2882 | zone2 | FOLLOWER | mysql001 | USER | | 1002 | 1001 | xx.xx.xx.237 | 2882 | zone1 | LEADER | mysql001 | USER | | 1002 | 1001 | xx.xx.xx.238 | 2882 | zone2 | FOLLOWER | mysql001 | USER | +-----------+-------+----------------+----------+-------+----------+-------------+-------------+ 8 rows in set ``` 有关 `CDB_OB_LS_LOCATIONS` 视图的更多信息，参见 [CDB_OB_LS_LOCATIONS](https://www.oceanbase.com/docs/common-oceanbase-database-ai-1000000006779822)。 3. 执行以下命令切主。 ```sql ALTER SYSTEM SWITCH REPLICA role LS [=] ls_id SERVER [=] 'ip:port' TENANT = tenant_name; ``` 相关参数说明如下： - `role`：副本角色，用于指定日志流副本的角色为 LEADER 或 FOLLOWER。 - `ls_id`：待修改的日志流副本的 ID。 - `ip:port`：待修改的日志流副本所在主机的 IP 和 RPC 端口。 - `tenant_name`：待修改的日志流副本所属的租户。 示例如下： ```shell obclient [(none)]> ALTER SYSTEM SWITCH REPLICA LEADER LS = 1001 SERVER = 'xx.xx.xx.238:2882' TENANT = mysql001; ``` 4. 操作结束后，可以再次查询视图，确认副本角色是否修改成功。 ```shell obclient [(none)]> SELECT * FROM oceanbase.CDB_OB_LS_LOCATIONS WHERE TENANT_ID = 1010; ``` 查询结果如下： ```shell +----------------------------+----------------------------+-----------+-------+----------------+----------+----------+-------+----------+-------------------------------------------------------------------+----------------------+--------------+--------------+---------+ | CREATE_TIME | MODIFY_TIME | TENANT_ID | LS_ID | SVR_IP | SVR_PORT | SQL_PORT | ZONE | ROLE | MEMBER_LIST | PAXOS_REPLICA_NUMBER | REPLICA_TYPE | LEARNER_LIST | REBUILD | +----------------------------+----------------------------+-----------+-------+----------------+----------+----------+-------+----------+-------------------------------------------------------------------+----------------------+--------------+--------------+---------+ | 2022-12-26 18:28:49.389601 | 2022-12-26 18:28:54.441143 | 1010 | 1 | xx.xx.xx.237 | 2882 | 2881 | zone1 | LEADER | xx.xx.xx.237:2882:1,xx.xx.xx.238:2882:1 | 2 | FULL | | FALSE | | 2022-12-26 18:28:49.390567 | 2023-01-11 12:02:37.970540 | 1010 | 1 | xx.xx.xx.238 | 2882 | 2881 | zone2 | FOLLOWER | NULL | NULL | FULL | | FALSE | | 2022-12-26 18:29:01.334732 | 2023-01-11 11:59:31.899581 | 1010 | 1001 | xx.xx.xx.238 | 2882 | 2881 | zone2 | LEADER | xx.xx.xx.237:2882:1,xx.xx.xx.238:2882:1 | 2 | FULL | | FALSE | | 2022-12-26 18:29:01.335629 | 2023-01-11 12:02:37.709677 | 1010 | 1001 | xx.xx.xx.237 | 2882 | 2881 | zone1 | FOLLOWER | NULL | NULL | FULL | | FALSE | +----------------------------+----------------------------+-----------+-------+----------------+----------+----------+-------+----------+-------------------------------------------------------------------+----------------------+--------------+--------------+---------+ 6 rows in set ``` 主动切主适用于机房容灾和城市容灾场景，您可以将 Leader 切换到指定的 Zone 或者 Region，从而更加契合应用流量的分布。 ### 单副本场景容灾操作 单副本部署场景，计算节点故障后，需要在其他可用节点上重新拉起故障的日志流副本。不同故障场景对应的容灾操作如下： | 故障场景 | 容灾操作 | 适用对象 | 拉起位置 | 触发方式 | 操作粒度 | | --- | --- | --- | --- | --- | --- | | 部分计算节点不可用，可用区（AZ）内存在可用节点，或可以添加其他节点 | `REPLACE LS` | 用户租户 | 可用区（AZ）内 | 手动逐条执行 | 日志流 | | 部分计算节点不可用，可用区（AZ）内既无可用节点、也无法添加其他节点 | `ALTER TENANT`（变更 Locality） | 用户租户 | 跨可用区（AZ） | 手动执行 + RS 自动发起容灾任务 | 租户 | | 整个可用区（AZ）的计算节点全部不可用 | `REPLACE TENANT`（恢复系统租户）+ 变更 Locality（逐个恢复用户租户） | 系统租户和用户租户 | 跨可用区（AZ） | 手动执行 + RS 自动发起容灾任务 | 租户 | #### 场景一：部分计算节点不可用，可用区（AZ）内存在可用节点，或可以添加其他节点 在可用区（AZ）内替换日志流时，系统不会自动触发 Replace 任务。需要在集群上查询故障机器上有哪些日志流（可通过 `CDB_OB_LS_LOCATIONS` 视图按 `SVR_IP`、`SVR_PORT` 查询），针对这些日志流逐条执行 `REPLACE LS` 命令，重建故障的日志流。 `REPLACE LS` 命令语法如下： ```sql ALTER SYSTEM REPLACE LS [=] SERVER [=] ':' [TENANT [=] '']; ``` 相关参数说明如下： - `LS`：日志流 ID，必须是整数，例如 `1`、`1001`。不能写成字符串。 - `SERVER`：目标节点的 RPC 地址，格式必须是 `ip:rpc_port`。只写 IP、不写端口会报参数错误。 - `TENANT`：（可选）日志流所属的租户。使用 sys 租户操作 Meta 租户时，格式为 `META$`，例如 `META$1002`；省略时，使用当前会话所在的租户。 #### 说明 - 子句顺序固定：必须先写 `LS`，再写 `SERVER`，最后才是可选的 `TENANT`，调换顺序会语法错误。 - 不支持只写 `REPLACE SERVER` 或 `REPLACE TENANT` 等残缺形式。 以用户租户 `mysql_tenant`（租户 ID 为 1002）为例，操作步骤如下： 1. 在可用区（AZ）内添加或启用新节点，并执行 `ALTER SYSTEM ADD SERVER` 将新节点加入集群： ```sql ALTER SYSTEM ADD SERVER 'ip:port' ZONE 'zone1'; ``` 2. 将该租户的 Unit 迁移到新节点。新节点上必须有该租户的 Unit，`REPLACE LS` 命令才能执行： ```sql ALTER SYSTEM MIGRATE UNIT unit_id DESTINATION 'ip:port'; ``` 其中，`unit_id` 为待迁移的 Unit ID，`ip:port` 为新节点的 IP 和 RPC 端口。 3. 依次执行以下 `REPLACE LS` 命令： #### 注意 执行 `REPLACE LS` 命令前，需满足以下条件，任一不满足都会报错： - 目标节点存活、允许迁入且非永久下线，并已有该租户的 Unit。 - 该日志流成员列表中的所有机器均已不可用（`INACTIVE`），只要还有一台存活，命令会拒绝执行。 - 目标节点上还没有该日志流的副本，且该日志流上没有正在执行的其他容灾任务。 `REPLACE LS` 建议在 sys 租户中执行；在用户租户中执行时，只能操作本租户。 1. 先恢复 Meta 租户日志流： ```sql ALTER SYSTEM REPLACE LS = 1001 SERVER = 'ip:port' TENANT = 'META$1002'; ALTER SYSTEM REPLACE LS = 1 SERVER = 'ip:port' TENANT = 'META$1002'; ``` 2. 再恢复用户租户日志流： ```sql ALTER SYSTEM REPLACE LS = 1 SERVER = 'ip:port' TENANT = 'mysql_tenant'; ``` 如有其他用户日志流，继续逐条执行。 命令成功返回只表示任务已被系统受理，不代表日志流已恢复，请等待任务执行成功后，再执行下一条命令。 4. 按以下方式判断单条任务是否执行成功，以下条件需同时满足： - `CDB_OB_LS_REPLICA_TASKS` 视图中该租户、该 `ls_id` 的 `REPLACE REPLICA` 任务已消失： ```sql SELECT * FROM oceanbase.CDB_OB_LS_REPLICA_TASKS WHERE TENANT_ID = 1002 AND LS_ID = 1 AND TASK_TYPE = 'REPLACE REPLICA'; ``` - `CDB_OB_LS_REPLICA_TASK_HISTORY` 视图中对应历史记录的 `TASK_STATUS` 为 `COMPLETED`，且 `EXECUTE_RESULT` 为 `OB_SUCCESS`： ```sql SELECT TASK_STATUS, EXECUTE_RESULT, TASK_TYPE, GMT_CREATE FROM oceanbase.CDB_OB_LS_REPLICA_TASK_HISTORY WHERE TENANT_ID = 1002 AND LS_ID = 1 AND TASK_TYPE = 'REPLACE REPLICA' ORDER BY GMT_CREATE DESC; ``` 在用户租户中查询时，可使用 `DBA_OB_LS_REPLICA_TASKS` 和 `DBA_OB_LS_REPLICA_TASK_HISTORY` 视图（仅包含本租户数据）。 历史记录中 `TASK_STATUS` 非 `COMPLETED` 或 `EXECUTE_RESULT` 非 `OB_SUCCESS`，表示任务执行失败，请结合报错信息决定是否重试。 任务成功后，还可通过以下方式验证业务可用： - 确认该日志流的 Leader 已位于目标节点： ```sql SELECT TENANT_ID, LS_ID, ROLE, SVR_IP, SVR_PORT FROM oceanbase.CDB_OB_LS_LOCATIONS WHERE TENANT_ID = 1002 AND LS_ID = 1 AND ROLE = 'LEADER'; ``` - 对该租户做简单读写（如建表、插入、查询），确认业务正常。 5. 该租户的所有日志流恢复完成后，确认 Unit 迁移结束（`DBA_OB_UNITS` 视图中 `MIGRATE_FROM_SVR_IP` 和 `MIGRATE_FROM_SVR_PORT` 字段清空），按运维规范删除故障机器。 #### 场景二：部分计算节点不可用，可用区（AZ）内既无可用节点、也无法添加其他节点 恢复前，请在新可用区（AZ）添加足够的计算节点，用于承载恢复后的日志流副本。同时，确认该租户在故障可用区（AZ）的所有计算节点均已处于 `INACTIVE` 状态（可通过 `DBA_OB_SERVERS` 视图查询）。对集群中的每个用户租户，依次执行以下操作： 1. 锁定租户。 ```sql ALTER TENANT mysql_tenant LOCK; ``` 2. 扩展租户资源池的 `ZONE_LIST`。单副本部署的租户只有一个资源池，通过将新可用区（AZ）的 Zone 加入资源池的 `ZONE_LIST`，为恢复后的日志流副本提供资源。 ```sql ALTER RESOURCE POOL mysql_tenant_pool ZONE_LIST = ('zone1', 'zone2'); ``` 3. 将租户的 Locality 从故障可用区（AZ）直接变更到新可用区（AZ）。Locality 变更后，RS 自动发起单副本容灾任务，在新可用区（AZ）中拉起该租户的日志流副本。 ```sql ALTER TENANT mysql_tenant LOCALITY = 'F@zone2'; ``` 4. 判断容灾任务是否完成。可通过以下任一方式判断： - `DBA_OB_TENANT_JOBS` 视图中对应任务的 `JOB_STATUS` 为 `SUCCESS`。 ```sql SELECT * FROM oceanbase.DBA_OB_TENANT_JOBS WHERE TENANT_ID = 1002; ``` - `DBA_OB_TENANTS` 视图中该租户的 `PREVIOUS_LOCALITY` 列为 `NULL`。 ```sql SELECT TENANT_ID, TENANT_NAME, LOCALITY, PREVIOUS_LOCALITY FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_ID = 1002; ``` #### 说明 若发起单副本容灾任务之前，租户还有未完成的资源规格变更任务，`DBA_OB_TENANT_JOBS` 中的 `JOB_STATUS` 需要等前一个任务完成后才会标记为 `SUCCESS`。此时建议以 `DBA_OB_TENANTS` 视图的 `PREVIOUS_LOCALITY` 是否为 `NULL` 作为判断依据。 5. 修改租户的 `PRIMARY_ZONE`，将主可用区（AZ）从故障可用区（AZ）变更为新可用区（AZ）。 ```sql ALTER TENANT mysql_tenant PRIMARY_ZONE='zone2'; ``` 6. 容灾任务完成后，收窄租户资源池的 `ZONE_LIST`，仅保留新可用区（AZ）的 Zone，移除故障可用区（AZ）的 Zone。 ```sql ALTER RESOURCE POOL mysql_tenant_pool ZONE_LIST = ('zone2'); ``` 7. 解锁租户，恢复业务访问。 ```sql ALTER TENANT mysql_tenant UNLOCK; ``` #### 场景三：整个可用区（AZ）的计算节点全部不可用 恢复前，请在新可用区（AZ）添加足够的计算节点，用于承载恢复后的日志流副本。然后按以下顺序依次恢复： 1. 在新可用区（AZ）的空机器上执行 `REPLACE TENANT` 恢复 sys 租户。 ```sql ALTER SYSTEM REPLACE TENANT = 'sys' REGION = 'region_name' ZONE = 'zone2' SERVER = 'ip:port' LOGSERVICE_ACCESS_POINT 'ip:port' SHARED_STORAGE_INFO 'shared_storage_info'; ``` 该命令会在新可用区（AZ）的空机器上拉起 sys 租户的日志流。 2. sys 租户恢复后，修改 sys 租户的 Locality。 ```sql ALTER TENANT sys LOCALITY = 'F@zone2'; ``` #### 说明 如果执行 `ALTER TENANT sys LOCALITY = 'F@zone2';` 操作失败，可重启 RS 后重试该命令。 3. 对集群中的每一个用户租户，执行场景二中的步骤 1 至步骤 7，将该租户的日志流副本从故障可用区（AZ）恢复到新可用区（AZ）。 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线