后台巡检导致 RS 上任失败

问题现象

当 Root Service (RS) 发生非预期卸任时，如果后台的 root_inspection 巡检任务正在运行且未退出，RS 的卸任流程可能会被阻塞。最坏情况下，阻塞可能持续约 1000 秒，直至后台巡检任务超时结束。

此问题可能导致以下现象：

• 所有发送给 RS 的运维命令都会阻塞直至超时。
• 后台日志中报错 cost too much time to wait rs stop。
• 集群的 DDL 操作无法执行。

关键诊断信息

触发条件

满足以下条件时，可能触发此问题：

1. RS 曾发生过卸任。
2. 集群负载过高，导致单次 root_inspection 巡检执行时间超过 10 分钟。
3. 在 RS 卸任前，用户手动执行了 root_inspection，或者后台正在执行周期性的巡检任务。

事前巡检

此问题主要由 RS 的非预期卸任引发，而 RS 卸任可能由选举异常等难以预测的原因导致，因此事前较难进行有效巡检。

事后诊断

问题发生后，可通过以下方式快速定位：

1. 检查日志：在集群恢复后，检查日志中是否存在 ERROR 级别的报错 cost too much time to wait rs stop。该日志通常在问题已恢复后打印，可用于回溯判断。
2. 查询内部表：执行以下 SQL 查询，检查 RS 卸任事件序列。

   SELECT * 
   FROM __all_rootservice_event_history 
   WHERE module = 'root_service' 
     AND event IN ('start_rootservice', 'finish_start_rootservice', 'stop_rootservice', 'finish_stop_thread', 'finish_wait_stop', 'full_rootservice') 
   ORDER BY gmt_create DESC 
   LIMIT 1;
   

   • 如果查询结果中最新事件的 event 字段为 finish_stop_thread，且后续没有出现 finish_wait_stop 事件，则表明 RS 卸任流程在等待后台线程退出时被卡住。

问题原因

为优化性能，root_inspection 巡检任务被改为分发到各租户的 Leader 上并行执行。这会占用 RS 后台的异步线程以及各租户 Leader 上的线程。

当前的退出机制是检测到 RS Leader 发生变化时，相关线程即退出。然而，在 RS Leader 未变更但 RS 自身发生卸任的场景下，租户上的线程无法感知到 RS 卸任事件，导致这些线程无法及时退出，从而阻塞了 RS 的卸任流程。

问题的风险及影响

• RS 功能受影响，无法处理运维命令。
• 集群 DDL 操作无法执行。

影响租户

影响版本

查看详细受影响版本

解决方法

方法一：手动切换 RS Leader

当前 root_inspection 在租户 Leader 上执行时会检查 RS Leader 是否与发起 RPC 的 RS Leader 一致，若不一致则退出。因此，可以通过手动将 RS Leader 切换至另一台机器，促使巡检 RPC 处理退出，从而释放 RS 上的线程，使卸任流程得以继续。

操作步骤

1. 确认当前 RS Leader：

   SELECT * 
   FROM __all_virtual_ls_meta_table 
   WHERE tenant_id = 1 
     AND ls_id = 1;
   

   其中 role = 1 的机器即为当前 RS Leader 所在机器，假设为 A。另选一台非 A 的机器作为目标，假设为 B。

2. 记录当前手动选举配置：

   SELECT * 
   FROM __all_ls_election_reference_info 
   WHERE tenant_id = 1 
     AND ls_id = 1;
   

   记录 manual_leader_server 字段的当前值，假设为 C。

3. 修改系统租户 Leader 为机器 B：

   UPDATE __all_ls_election_reference_info 
   SET manual_leader_server = 'x.x.x.x:xxxx' 
   WHERE tenant_id = 1 
     AND ls_id = 1;
   

   将 manual_leader_server 设置为机器 B 的地址。

4. 观察 RS Leader 切换：

   SELECT * 
   FROM __all_virtual_ls_meta_table 
   WHERE tenant_id = 1 
     AND ls_id = 1;
   

   确认 RS Leader 已成功切换到机器 B。

5. 验证卸任流程完成：

   SELECT * 
   FROM __all_rootservice_event_history 
   WHERE module = 'root_service' 
     AND event IN ('start_rootservice', 'finish_start_rootservice', 'stop_rootservice', 'finish_stop_thread', 'finish_wait_stop', 'full_rootservice') 
   ORDER BY gmt_create DESC 
   LIMIT 1;
   

   确认最新事件的 event 字段为 full_rootservice，表示 RS 已成功完成卸任并重新就任。

6. 恢复手动选举配置（可选）：

   ALTER SYSTEM SWITCH REPLICA leader LS = 1 SERVER = 'x.x.x.x:x' TENANT = sys;
   

   将 RS Leader 修改回之前记录的地址 C。

方法二：重启阻塞节点

重启 RS 卸任流程被卡住的那台 OceanBase 服务器节点。此操作会强制终止所有后台线程，包括阻塞的巡检任务，从而使 RS 能够完成卸任流程。

规避方式

目前无有效的规避手段。