OBServer 状态变为 inactive

适用版本

OceanBase 数据库所有版本

问题现象

系统监控视图 __all_server 中显示有 OBServer 节点的状态为 inactive，登陆节点看到 observer 进程是存在的。

问题原因

作为一个分布式数据库系统，OceanBase 集群需要感知每个 OBServer 节点的状态，当节点状态异常时，会主动把节点设置为 inactive 状态。如果 observer 进程存在，但节点状态是 inactive，通常是以下原因导致。

1. 进程异常，正在执行 core dump 动作。因为内存大，所以过程持续时间长，inactive 后仍然看到进程 PID 存在。
2. 进程没有发生 core dump，但是发生了线程死锁等问题。
3. 网络问题，OBServer 与其他节点的通信异常，Root Service 无法探测该问题节点的心跳。

OBServer 状态监测

作为集群的中控服务，Root Service 负责集群的 OBServer 管理，各 OBServer 通过心跳数据包（heartbeat）的方式，定期（每 2s）向 Root Service 汇报自己的进程状态，Root Service 通过监测 OBServer 的心跳数据包，来获取当前 OBServer 进程的工作状态。

OBServer 心跳状态相关配置项。

• lease_time：心跳租约时长，默认值 10s。
  • 当 RS 累计超过 lease_time 时间没有收到过某 OBServer 的任意心跳数据包时，Root Service 认为该 observer 进程短暂断线，Root Service 会标记该 OBServer 设置为 inactive 状态。
  • 如果 RS 再次收到 OBServer 的心跳信息，会把 OBServer 的状态从 inactive 变为 active，同时进行副本数据追平的操作。
• server_permanent_offline_time：永久下线时间，默认值 3600s，即 1 小时。
  • 当 RS 累计超过 server_permanent_offline_time 时间没有收到过某 OBServer 的任意心跳数据包时，RS 认为该 OBServer 进程断线，RS 会标记该 OBServer 为永久下线（offline）。
  • 如果 OBServer 被永久下线，那么再次拉起后，节点中的所有副本都会被清空（被 RS 踢出 Paxos 成员列表），其上的全部数据都需要从其他副本重新拉取。

解决方法

根据发生问题的原因，采取以下策略来应对。

1. 如果是进程异常，observer 进程 core dump。建议等待 core dump 保存结束再重启 observer 进程。 如果在 core dump 的过程中，使用 kill -9 pgrep observer 杀掉进程，则会终止 core dump 的保存，让 dump 不完整。
2. 如果 observer 进程发生死锁等问题导致hang，需要通过 kill -6 pgrep observer 手动触发 core dump。等待 core dump 保存结束后，手动启动进程。
   • 同时建议在 kill -6 pgrep observer 之前，运行 2 次 pstack pgrep observer >> output，来保存pstack 信息辅助问题的排查。
   • 不建议使用 gcore 命令。此命令常常因 gdb 无法正常保存 core 而引起 core dump 损坏。
3. 如果怀疑是网络问题，可以通过 ping、sar 或者 tsar 工具来诊断网络问题，及时通知网络管理员来进行处理。