数据库层高可用

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。

  当 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。

  当 Root Service 累计超过 server_permanent_offline_time 时间没有收到过某 OBServer 的任意心跳数据包时，Root Service 认为该 observer 进程断线，Root Service 会标记该 OBServer 的心跳状态为 permanent_offline。

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 的详细操作请参见 隔离节点。

节点隔离适用于单机房故障场景：

• 非通断型故障（例如网卡丢包导致的机器不稳定）强依赖节点隔离，否则会发生反复切主而影响应用。

• 通断型故障（例如机器直接宕机）不强依赖节点隔离，其会在 oceanbase.DBA_OB_SERVERS 视图标记节点状态为 INACTIVE 而隔离应用流量。

在节点隔离或者 Leader 出现故障时，会触发选举。选举服务的优先级机制会考虑用户指定的 Primary Zone，考虑机器的异常状态等，从而保证选择更优的副本作为主副本。

容灾操作

OceanBase AI 数据库采用存算分离架构，通过高可用日志服务提供数据的持久性，保证数据不丢失（RPO=0），通过多副本计算节点保障数据的高可用。副本数不同，对应的容灾操作也不同：两副本部署支持手动切主，单副本部署支持可用区（AZ）内或跨可用区（AZ）容灾。有关副本部署场景的详细介绍，参见 容灾部署方案。

两副本场景容灾操作

对于计算节点两副本部署场景，除了隔离节点，您还可以主动切主，切换日志流副本的主备角色。

主动切主的操作步骤如下：

1. 使用 root 用户登录到集群的 sys 租户。

   连接示例如下，连接数据库时请以实际环境为准。

   obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
   

   有关更加详细的连接数据库的操作指引，参见 连接数据库概述。

2. 获取租户的 Zone、Server 及日志流副本信息。

   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;
   

   查询结果如下：

   +-----------+-------+----------------+----------+-------+----------+-------------+-------------+
   | 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。

3. 执行以下命令切主。

   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：待修改的日志流副本所属的租户。

   示例如下：

   obclient [(none)]> ALTER SYSTEM SWITCH REPLICA LEADER LS = 1001 SERVER = 'xx.xx.xx.238:2882' TENANT = mysql001;
   

4. 操作结束后，可以再次查询视图，确认副本角色是否修改成功。

   obclient [(none)]> SELECT * FROM oceanbase.CDB_OB_LS_LOCATIONS WHERE TENANT_ID = 1010;
   

   查询结果如下：

   +----------------------------+----------------------------+-----------+-------+----------------+----------+----------+-------+----------+-------------------------------------------------------------------+----------------------+--------------+--------------+---------+
   | 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）内存在可用节点，或可以添加其他节点

在可用区（AZ）内替换日志流时，系统不会自动触发 Replace 任务。需要在集群上查询故障机器上有哪些日志流（可通过 CDB_OB_LS_LOCATIONS 视图按 SVR_IP、SVR_PORT 查询），针对这些日志流逐条执行 REPLACE LS 命令，重建故障的日志流。

REPLACE LS 命令语法如下：

ALTER SYSTEM REPLACE LS [=] <ls_id>
  SERVER [=] '<ip>:<rpc_port>'
  [TENANT [=] '<tenant_name>'];

相关参数说明如下：

• LS：日志流 ID，必须是整数，例如 1、1001。不能写成字符串。

• SERVER：目标节点的 RPC 地址，格式必须是 ip:rpc_port。只写 IP、不写端口会报参数错误。

• TENANT：（可选）日志流所属的租户。使用 sys 租户操作 Meta 租户时，格式为 META$<user_tenant_id>，例如 META$1002；省略时，使用当前会话所在的租户。

以用户租户 mysql_tenant（租户 ID 为 1002）为例，操作步骤如下：

1. 在可用区（AZ）内添加或启用新节点，并执行 ALTER SYSTEM ADD SERVER 将新节点加入集群：

   ALTER SYSTEM ADD SERVER 'ip:port' ZONE 'zone1';
   

2. 将该租户的 Unit 迁移到新节点。新节点上必须有该租户的 Unit，REPLACE LS 命令才能执行：

   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 租户日志流：

      ALTER SYSTEM REPLACE LS = 1001 SERVER = 'ip:port' TENANT = 'META$1002';
      ALTER SYSTEM REPLACE LS = 1 SERVER = 'ip:port' TENANT = 'META$1002';
      

   2. 再恢复用户租户日志流：

      ALTER SYSTEM REPLACE LS = 1 SERVER = 'ip:port' TENANT = 'mysql_tenant';
      

   如有其他用户日志流，继续逐条执行。

   命令成功返回只表示任务已被系统受理，不代表日志流已恢复，请等待任务执行成功后，再执行下一条命令。

4. 按以下方式判断单条任务是否执行成功，以下条件需同时满足：

   • CDB_OB_LS_REPLICA_TASKS 视图中该租户、该 ls_id 的 REPLACE REPLICA 任务已消失：

     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：

     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 已位于目标节点：

     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. 锁定租户。

   ALTER TENANT mysql_tenant LOCK;
   

2. 扩展租户资源池的 ZONE_LIST。单副本部署的租户只有一个资源池，通过将新可用区（AZ）的 Zone 加入资源池的 ZONE_LIST，为恢复后的日志流副本提供资源。

   ALTER RESOURCE POOL mysql_tenant_pool ZONE_LIST = ('zone1', 'zone2');
   

3. 将租户的 Locality 从故障可用区（AZ）直接变更到新可用区（AZ）。Locality 变更后，RS 自动发起单副本容灾任务，在新可用区（AZ）中拉起该租户的日志流副本。

   ALTER TENANT mysql_tenant LOCALITY = 'F@zone2';
   

4. 判断容灾任务是否完成。可通过以下任一方式判断：

   • DBA_OB_TENANT_JOBS 视图中对应任务的 JOB_STATUS 为 SUCCESS。

     SELECT * FROM oceanbase.DBA_OB_TENANT_JOBS WHERE TENANT_ID = 1002;
     

   • DBA_OB_TENANTS 视图中该租户的 PREVIOUS_LOCALITY 列为 NULL。

     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）。

   ALTER TENANT mysql_tenant PRIMARY_ZONE='zone2';
   

6. 容灾任务完成后，收窄租户资源池的 ZONE_LIST，仅保留新可用区（AZ）的 Zone，移除故障可用区（AZ）的 Zone。

   ALTER RESOURCE POOL mysql_tenant_pool ZONE_LIST = ('zone2');
   

7. 解锁租户，恢复业务访问。

   ALTER TENANT mysql_tenant UNLOCK;
   

场景三：整个可用区（AZ）的计算节点全部不可用

恢复前，请在新可用区（AZ）添加足够的计算节点，用于承载恢复后的日志流副本。然后按以下顺序依次恢复：

1. 在新可用区（AZ）的空机器上执行 REPLACE TENANT 恢复 sys 租户。

   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。

   ALTER TENANT sys LOCALITY = 'F@zone2';
   

   说明

   如果执行 ALTER TENANT sys LOCALITY = 'F@zone2'; 操作失败，可重启 RS 后重试该命令。

3. 对集群中的每一个用户租户，执行场景二中的步骤 1 至步骤 7，将该租户的日志流副本从故障可用区（AZ）恢复到新可用区（AZ）。