后台巡检导致 RS 上任失败

问题现象

问题场景：

RS Leader 原本在 A，因为各种原因 RS 卸任，卸任后由于 Leader 没变，或者是 Leader 变成了 B 但是很快又变成了 A。这种场景下 RS 卸任可能因为 root_inspection 正在运行，后台线程没有退出而被卡住。预期最坏情况下会被卡住 1000s，直到后台 root_inspection 超时结束。 可能出现的问题如下：

• 所有发给RS的运维命令都会卡住直到超时。

• 后台 ERROR 报错 cost too much time to wait rs stop。

• DDL 无法执行。

关键诊断信息

触发条件

• RS 出现过卸任的情况。

• 集群压力过大导致 root_inspection 过慢，单次 root_inspection 超过 10 min。

• RS 卸任前，用户手动执行了 root_inspection，或者后台正在执行 10 min 一次的巡检。

事前巡检

出现问题主要是因为 RS 非预期卸任了，这可能是因为选举异常导致短暂无主，较难巡检。

事后诊断

• 日志里 RS 卸任超过 10 min 会报错 ERROR 日志 cost too much time to wait rs stop，不过这个是集群恢复了才会打印，只能在集群恢复后判断之前是否是这个问题。

• 通过查询语句 select * from oceanbase.__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 的性能，现在 root_inspection 改为了发到每个租户 Leader 上并行执行，这会占用rs的后台异步线程以及租户 Leader 上的线程。 为了避免 RS 切主导致线程未及时退出的情况，目前是检测 RS Leader 发生变化了就退出。在 RS Leader 没变但是 RS 卸任的情况下这会导致租户线程无法感知 RS 卸任了，因此会卡住 RS 卸任。

问题的风险及影响

无法执行运维命令和 DDL，RS 功能受影响。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

影响版本

OceanBase 数据库企业版 V4.3.5 BP4（oceanbase-4.3.5.4-104000052025090918）及之后版本、V4.4.1（oceanbase-4.4.1.0-100000242025092415）及之后版本。

解决方法

方法一：

升级到问题已修复版本。目前已修复的版本包含 OceanBase 数据库企业版 V4.3.5 BP4 Hotfix3（oceanbase-4.3.5.4-104030042025102723）版本、V4.3.5 BP4 Hotfix4（oceanbase-4.3.5.4-104040012025110519）版本、V4.3.5 BP4 Hotfix5（oceanbase-4.3.5.4-104050022025112417）版本、V4.3.5 BP4 Hotfix6（oceanbase-4.3.5.4-104060012025121519）版本、V4.3.5 BP4 Hotfix7（oceanbase-4.3.5.4-104070022026010511）版本、V4.3.5 BP4 Hotfix8（oceanbase-4.3.5.4-104080012026020919）版本、V4.3.5 BP4 Hotfix9（oceanbase-4.3.5.4-104090012026021115）版本、V4.3.5 BP4 Hotfix10（oceanbase-4.3.5.4-104100022026031614）版本、V4.3.5 BP4 Hotfix11（oceanbase-4.3.5.4-104110022026032015）版本、V4.3.5 BP4 Hotfix12（oceanbase-4.3.5.4-104120022026040910）版本、V4.3.5 BP4 Hotfix13（oceanbase-4.3.5.4-104130012026042014）版本、V4.3.5 BP5（oceanbase-4.3.5.5-105000212025111617）及之后版本、V4.4.1 Hotfix3（oceanbase-4.4.1.0-100030042025102815）版本、V4.4.1 Hotfix4（oceanbase-4.4.1.0-100040012025111319）版本、V4.4.1 Hotfix5（oceanbase-4.4.1.0-100050012025112008）版本、V4.4.1 Hotfix6（oceanbase-4.4.1.0-100060042025120221）版本、V4.4.1 Hotfix7（oceanbase-4.4.1.0-100070032025121810）版本、V4.4.1 Hotfix8（oceanbase-4.4.1.0-100080022025122410）版本、V4.4.1 Hotfix9（oceanbase-4.4.1.0-100090032026012721）版本、V4.4.1 Hotfix10（oceanbase-4.4.1.0-100100032026020816）版本、V4.4.1 Hotfix11（oceanbase-4.4.1.0-100110052026031016）版本、V4.4.1 Hotfix12（oceanbase-4.4.1.0-100120022026032610）版本。

方法二：

手动将 RS 切主。因为 root_inspection 现在在租户 Leader 上执行时会检查 RS Leader 与发 RPC 的 RS Leader 是否相同，不相同则退出。因此只要将 RS Leader 切换为一个非当前 RS 的机器，就能让 RPC 处理退出，进而 RS 上的线程退出，让 RS 卸任顺利执行下去。 执行查询语句 select * from __all_virtual_ls_meta_table where tenant_id=1 and ls_id=1;，其中 role=1 的机器为 RS 当前 Leader 所在机器，假设为 A，其他机器找一台为 B，执行查询语句 select * from __all_ls_election_reference_info where tenant_id=1 and ls_id=1;，记录当前 manual_leader_server 的值，假设为 C。更新语句 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，将系统租户 Leader 修改为 B，执行查询语句 select * from __all_virtual_ls_meta_table where tenant_id=1 and ls_id=1; 观察 RS Leader 切主 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; 最新一项为 full_rootservice。执行如下命令 ALTER SYSTEM SWITCH REPLICA leader LS = 1 SERVER = 'x.x.x.x:x' TENANT = sys; 将 RS Leader 修改为 C。

方法三：

将 RS 卸任卡住的机器重启。

规避方式

无。