【OceanBase】OBServer 重启失败问题排查

本文主要介绍排查 OBServer 重启失败问题的步骤。

适用版本

OceanBase 数据库所有版本

问题排查思路

在 OBServer 重启之后，发现 OBServer 不能正常提供服务，需要进一步排查 OBServer 启动失败的原因。一般按照如下思路进行问题排查。

1. 先检查 OBServer 启动前进行的变更

若启动前曾进行变更如参数修改、环境更改等，应先考虑是否是变更带来的影响。在时间及变更回退影响允许的情况下，应进行变更回退排除变更影响。此后在测试环境进行问题重现并进一步诊断根因。

2. 进行其他相关排查

在目前已知场景中，导致导致 OBServer 重启失败的常见原因有 NTP 不同步、网络异常、Schema 刷新异常、心跳异常等。为确定根因，请按照如下步骤进行问题排查。

问题排查步骤

在 OBServer 启动失败后，首先查看observer.log 是否有明显报错，如果有明显报错请先按照报错信息处理，详细信息请参见 《 参考指南（MySQL 模式） 》中的 错误码 和 《 参考指南（Oracle模式） 》中的 错误码 ；如果没有明显报错，请排查机器基础环境。

查看 observer.log

在 OBServer 启动失败后，OBServer 会将启动失败的错误日志打印在 observer.log 中。您可通过 grep ERROR observer.log 命令查看 OBServer 启动失败的原因。

通常情况下，如果在启动阶段有明显的 ERROR 级别日志报错，会给出启动失败的直接线索。您可结合 observer.log 里的报错信息并结合下文中的场景进行排查。RootService 正常启动的日志如下图所示：

定位故障节点

定位 __all_core_table 的 leader 所在机器，具体命令如下：

grep "1099511627777" election.log

上图中显示的 IP 和 PORT 即为故障节点信息。

检查 OBServer 的基础模块

1. 排查 RootService 是否启动异常。

a. 查询 __all_virtual_core_meta_table 表，如果返回空集，则说明 RootService 异常。

obclient> SELECT * FROM __all_virtual_core_meta_table;

b. 排查 RootService 的服务是否已经进入 START_SERVICE 的正常状态。根据 ob_restart 信息，可以拿到 TRACE_ID，在 observer.log 和 rootservice.log 展开 trace 看报错位置。

grep "START_SERVICE" rootservice.log

2. 排查集群 OBServer 心跳是否异常。

在故障 OBServer 的 observer.log 日志搜索 renew_lease，如果有返回值，说明存在心跳异常。

[admin@hostname log]$ grep "renew_lease" observer.log

3. 检查机器 Schema 是否存在刷新异常。

在故障 OBServer 的 observer.log 日志搜索 REFRESH_SCHEMA，如果有返回值，说明 Schema 刷新异常。

[admin@hostname log]$ grep "REFRESH_SCHEMA" observer.log

4. 排查是否存在 Clog 回放慢的问题。

在故障 OBServer 的 observer.log 日志搜索 NOTICE，如果存在clog is behind，service starting need to wait 信息，则说明是由于 Clog 回放慢造成的重启失败。

[admin@hostname log]$ grep "NOTICE" observer.log

检查机器基础环境

OBServer 的选举模块要求节点间的单向网络时延最好保证在 50ms 以内，最差也要在 100ms 以内；集群内要求主机之间的时钟同步时延在 100ms 以内。因此当时钟不同步或网络抖动时会导致重启失败等或其他严重的系统可用性问题。在遇到 OBServer 重启失败时，必须要先保证机器的基础环境是符合要求的。

• 使用 chronyc sources -v 或 ntpq -p方式验证时钟时效。
• 检查当前的网络设施是否异常，如异常考虑下线当前主机，具体操作请参见 故障 OBServer 节点替换。