当 OBServer 进程异常 crash，该节点上的分区副本会发生什么（） A. 所有分区数据直接丢失 B. Root Service 识别故障，触发分区 leader 重新选主 C. 集群立刻停止所有租户业务 D. 必须人工重启 OBServer 之后业务才恢复

培训 & 考证 实战分享
#1

当 OBServer 进程异常 crash，该节点上的分区副本会发生什么（）
A. 所有分区数据直接丢失
B. Root Service 识别故障，触发分区 leader 重新选主
C. 集群立刻停止所有租户业务
D. 必须人工重启 OBServer 之后业务才恢复

#2

正确答案是 B 。

当 OBServer 进程异常 crash 后，OceanBase 集群的高可用机制会自动处理，无需完全人工干预。

OceanBase 的 Root Service 服务自身基于 Paxos 协议实现了高可用，它会通过各节点每 2 秒发送一次的心跳包来监控进程状态。当检测到节点故障后，处理流程大致如下：

  1. 短暂失联 (lease_expired) ：Root Service 在短时间内（由 lease_time 配置项控制）未收到心跳，会将该节点标记为 inactive ，此时主要记录状态，不做进一步操作。
  2. 确认故障并自愈 (permanent_offline) ：当心跳丢失时间超过 server_permanent_offline_time 配置项（默认值通常较长，如1小时）时，节点被标记为永久下线 (permanent_offline )。此时，Root Service 会自动将该故障节点上的数据副本从 Paxos 成员组中移除，并在其他可用节点上补充新副本，确保数据副本总数和成员组完整
#3

答案：B

当 OBServer 进程异常 crash 时，该节点上的分区副本会经历以下过程：

:white_check_mark: B. RootService 识别故障，触发分区 Leader 重新选主

正确。当 OBServer 进程 crash 后，RootService 通过心跳机制（默认约 30 秒超时）检测到该节点失联，随即触发 Paxos 选举流程，将故障节点上承载的 Leader 副本角色迁移到其他健康的 Follower 副本上，新 Leader 接管读写服务，RTO 通常在 8~30 秒内完成。

具体机制如下：

  • 宕机节点承载 Leader 副本 ：其他存活节点上的 Follower 副本会在探活超时后，通过 Paxos 协议发起新一轮选举，推选出新 Leader 继续提供服务。
  • 宕机节点仅承载 Follower 副本 ：只要剩余副本仍满足多数派要求（如三副本中还有 2 个存活），Leader 可继续正常工作，前台业务几乎无感知。

:x: A. 所有分区数据直接丢失

错误。OceanBase 基于 Paxos 协议实现多副本强一致同步，事务提交的前提是 Clog 已成功落盘到多数派节点。因此即使某节点 crash，已提交的数据在其他副本上都有完整备份，RPO = 0，数据零丢失。

:x: C. 集群立刻停止所有租户业务

错误。只要集群仍满足多数派存活条件（如三副本宕机一台，剩余两台仍构成多数派），集群会继续正常提供服务，不会停止业务。只有当多数派副本不可用时，对应分区才会暂停服务。

:x: D. 必须人工重启 OBServer 之后业务才恢复

错误。Leader 的重新选举和切换是全自动 的，无需人工介入。即使该节点长时间无法恢复，RootService 也会在超过 server_permanent_offline_time （默认 1 小时）后自动将该节点永久下线，并在同 Zone 内其他健康节点上自动补齐副本，整个过程全自动完成。

:bulb: 核心记忆点：OBServer crash 后的关键流程是 “心跳超时检测 → Paxos 自动选主 → 业务自动恢复” ，全程无需人工干预，且数据零丢失。