集群重启后 reconfirm 超时导致集群不可用

问题现象

触发场景

OCP 所依赖的 MetaDB 是一个三节点的 OceanBase 集群，节点分别为 229、230 和 231。在对 MetaDB 所在的主机进行批量重启操作后，集群无法对外提供正常服务，导致 OCP 平台不可用。

具体表现

1. 节点连接失败 连接节点 230 和 231 时失败，报错信息为：ERROR 8001 (HY000): Server is initializing。

   

2. SQL 执行超时 在节点 229 上执行 SQL 语句超时，报错信息为：ERROR 4012 (HY000): Timeout。

   

3. 集群内部状态异常

   • 大量分区长时间处于 RECONFIRM 状态，无法选出稳定的 Leader。

     SELECT
     count(*)
     FROM
      __all_virtual_clog_stat
     GROUP BY
      table_id,
      partition_idx
     except
      (
        SELECT
          table_id,
          partition_idx
        FROM
         __all_virtual_clog_stat
       WHERE
          role = 'LEADER' );
     

   • RootService 不可用，出现 RS 无主或 fail to get rootserver 类错误。

   • election 层表现

     

     

     unconfirmed_leader:"10.22.65.231:2882"
     switch state error(ret=-4109, ...)
     check_decentralized_majority error(ret=-7004, ...)
     handle query leader error(ret=-7006/-7007, ...)
     

   选举层日志显示，节点 231 反复成为待确认 Leader (unconfirmed_leader)，但选举或 reconfirm 流程无法完成切换。相关错误信息包括： * switch state error(ret=-4109, ...) * check_decentralized_majority error(ret=-7004, ...) * handle query leader error(ret=-7006/-7007, ...)

4. 业务影响

   • 依赖 MetaDB 的 OCP 平台无法登录，也无法管理业务集群。
   • MetaDB 整体不可用。

问题原因

MetaDB 三节点重启后，集群进入恢复阶段。节点 231 因副本重建或日志落后，反复参与选举并成为待确认 Leader (unconfirmed_leader)。在执行 clog reconfirm 时，需要向多数派副本收集最大日志确认 (max log ACK)。对于三副本集群，需要获得 2 票确认。

然而，节点 229 的 clog 磁盘空间已满，导致其对节点 231 发起的 reconfirm 相关请求（如 handle_prepare_rqst、get_max_log_id 等）持续返回错误码 -4264（表示 clog 磁盘已满或无空间），无法提供有效的 Follower 确认。同时，节点 230 仍处于副本重建阶段。

因此，节点 231 侧出现 max_log_ack_list not majority 错误，单条日志任务的确认列表 (ack_list) 为 0。最终，大量分区的 reconfirm 操作超时，导致 RootService 及整个集群不可用。

关键信息

• 节点 229 clog 磁盘空间已满：在节点 229 的 observer.log 日志中，可以搜索到大量错误码 -4264 的记录。

  

• 节点 230 处于副本重建阶段：日志信息表明节点 230 正在进行副本重建 (rebuilding)。

  

问题的风险及影响

1. MetaDB 集群不可用，客户端连接会收到 8001 或 4012 错误，无法执行正常的 SQL 操作。
2. RootService 无主或长期处于 reconfirm 状态，元数据服务中断，影响 OCP 生态的正常运行。

适用版本

OceanBase 数据库 2.x 及 3.x 版本。

解决方法

扩容节点 229 的 clog 磁盘空间。

规避方式

不适用。