OBServer 重启失败问题排查
本文主要介绍排查 OBServer 重启失败问题的步骤。
一、适用版本
OceanBase 数据库所有版本
二、问题排查思路
在 OBServer 重启之后，发现 OBServer 不能正常提供服务，需要进一步排查 OBServer 启动
失败的原因。一般按照如下思路进行问题排查。
1，先检查 OBServer 启动前进行的变更
若启动前曾进行变更如参数修改、环境更改等，应先考虑是否是变更带来的影响。在时间
及变更回退影响允许的情况下，应进行变更回退排除变更影响。此后在测试环境进行问题
重现并进一步诊断根因。
2，进行其他相关排查
在目前已知场景中，导致导致 OBServer 重启失败的常见原因有 NTP 不同步、网络异常、
Schema 刷新异常、心跳异常等。为确定根因，请按照如下步骤进行问题排查。
三、 问题排查步骤
在 OBServer 启动失败后，首先查看 是否有明显报错，如果有明显报错请先按 observer.log
照报错信息处理，详细信息请参见 《 》中的 和 《 参考指南（MySQL 模式） 错误码 参考指
》中的 ；如果没有明显报错，请排查机器基础环境。 南（Oracle模式） 错误码
四、 查看 observer.log
在 OBServer 启动失败后，OBServer 会将启动失败的错误日志打印在 中。您 observer.log
可通过 命令查看 OBServer 启动失败的原因。 grep ERROR observer.log
通常情况下，如果在启动阶段有明显的 ERROR 级别日志报错，会给出启动失败的直接线索。
您可结合 里的报错信息并结合下文中的场景进行排查。RootService 正常启动 observer.log
的日志如下图所示：
五、定位故障节点
定位 的 leader 所在机器，具体命令如下： __all_core_table
grep "1099511627777" election.log
上图中显示的 IP 和 PORT 即为故障节点信息。
六、检查 OBServer 的基础模块
1，排查 RootService 是否启动异常。
查询 __all_virtual_core_meta_table表，如果返回空集，则说明 RootService 异 __all_virtual_core_meta_table
常。
obclient> SELECT * FROM __all_virtual_core_meta_table;
排查 RootService 的服务是否已经进入 的正常状态。根据 START_SERVICE
ob_restart 信息，可以拿到 TRACE_ID，在 和 展开 observer.log rootservice.log
trace 看报错位置。
grep "START_SERVICE" rootservice.log
2，排查集群 OBServer 心跳是否异常。
在故障 OBServer 的 日志搜索 ，如果有返回值，说明存在 observer.log renew_lease
心跳异常。
使用指南 OceanBase 数据库
2410 > 产品版本：V3.2.3
3.
4.
[admin@hostname log]$ grep "renew_lease" observer.log
检查机器 Schema 是否存在刷新异常。
在故障 OBServer 的 日志搜索 ，如果有返回值，说 observer.log REFRESH_SCHEMA
明 Schema 刷新异常。
[admin@hostname log]$ grep "REFRESH_SCHEMA" observer.log
排查是否存在 Clog 回放慢的问题。
在故障 OBServer 的 日志搜索 ，如果存在 observer.log NOTICE clog is behind，
信息，则说明是由于 Clog 回放慢造成的重启失败。 service starting need to wait
[admin@hostname log]$ grep "NOTICE" observer.log
580. .3 3. .2 2 检查机器基础环境
OBServer 的选举模块要求节点间的单向网络时延建议保证在 50ms 以内，最差也要在
100ms 以内；集群内要求主机之间的时钟同步时延在 100ms 以内。因此当时钟不同步或网络
抖动时会导致重启失败等或其他严重的系统可用性问题。在遇到 OBServer 重启失败时，必须
要先保证机器的基础环境是符合要求的。
使用 或 方式验证时钟时效。 chronyc sources -v ntpq -p
检查当前的网络设施是否异常，如异常考虑下线当前主机，具体操作请参见 [替换 observer
