OB 2.2.77 NTP 时钟偏移过大导致 OBServer 节点不工作

问题现象

OCP 告警页面触发 ob_cluster_exists_inactive_server 告警，提示 OceanBase 集群存在不工作的 OBServer。

触发场景及表现：

• 触发场景：跑批环境，ARM 架构，未进行人工操作，系统自动产生告警。
• 具体表现：
  • OCP 告警详情显示「OceanBase 集群存在不工作 OBServer」，不工作 OBServer 数量为 1。
  • 同一时间段伴随大量关联告警，包括 host_ntp_offset_too_large（服务器与时钟源偏移过大）、OBServer 报文响应时间过长、SQL 执行失败次数超限、OBServer 选举无日志、OBServer 错醒 location cache 超时等。
• 关键时间线：
  • 告警产生时间为 09:30:38，此时 ntp_offset_milliseconds 达到约 1300 ms（1.3 秒）。
  • 09:34 左右该 OBServer 被判定为不工作/不可用。
  • 09:39:16 告警自动恢复。
• 影响范围：
  • 受影响集群为 cs_ens。
  • 该节点不可用期间，集群可用性下降，跑批业务可能出现 SQL 失败或响应变慢。
• 发生频率：偶发，与 NTP 同步异常相关。

问题原因

OceanBase 是分布式数据库，各 OBServer 节点之间依赖时钟同步来维持一致性协议、RPC 通信和选主逻辑。当某节点与 NTP 时钟源的时间偏差超过阈值后，该节点与其他节点之间的通信会被认为异常，进而被集群判定为不工作。

根因分析：

• 该工单中，OCP 监控到 ntp_offset_milliseconds 达到约 1300 ms，远高于 100 ms 的停服阈值。
• 时间偏差过大后，OBServer 节点间 RPC 通信出现延迟、重传甚至超时，选举和 location cache 等内部机制无法正常工作，最终触发 ob_cluster_exists_inactive_server 告警。
• 是否为已知问题：这是 OceanBase 对时钟同步的常规依赖机制，属于预期行为，不是产品 Bug。OB 要求网络延迟 ≤50 ms（推荐），时钟偏差 ≤100 ms（最低）。

技术原理说明：

• OCP-Agent 通过 ntpq -p 或 chronyc tracking -n 采集 node_ntp_offset_seconds，换算为 ntp_offset_milliseconds。
• 当该指标超过 100 ms 时触发停服级别告警，超过 50 ms 时触发严重级别告警。
• 分布式系统通常依赖时钟同步来判定节点活性和处理超时，偏移过大会破坏这些假设。

关键信息

关键告警与指标

关键阈值

• 时钟偏移 > 100 ms：停服级别告警。
• 时钟偏移 > 50 ms：严重级别告警。
• OB 推荐网络延迟 ≤50 ms，时钟偏差 ≤100 ms。

诊断命令及预期结果

检查 NTP 同步状态

• 使用 ntp 服务时

ntpstat
ntpq -p

预期结果：应显示 synchronised to NTP server，且 offset 绝对值稳定在 50 ms 以内。

• 使用 chrony 服务时

chronyc sources -v
chronyc tracking -n

预期结果：Last offset 绝对值应在 50 ms 以内。

检查节点间网络延迟

clockdiff

预期结果：节点间网络延迟应 ≤50 ms。

检查租户请求队列是否积压

grep "dump tenant info" observer.log

预期结果：观察 total_size 是否持续过大，判断是否存在请求积压。

检查 coredump

cd /proc/sys/kernel
ll | grep core

cd /data/1
ll | grep core

预期结果：若存在 core-%e-%p-%t 类文件，说明节点发生过崩溃；本工单中这两个目录下未看到 16 号产生的 core 文件，排除 coredump 导致。

问题的风险及影响

• 业务影响程度：高。节点被判定为不工作后，集群可用副本数下降，跑批等业务可能出现 SQL 失败、响应时间变长或部分事务受阻。
• 系统风险评估：中。单节点异常若不及时恢复，可能演变为多节点异常，影响集群选举和负载均衡；本工单中告警在数分钟内自动恢复，风险可控。
• 是否有数据丢失风险：一般无直接数据丢失风险，因为 OceanBase 多副本机制可保障数据安全；但长时间时钟不同步可能引发一致性问题，需尽快处理。

影响租户

受影响节点上的所有租户。

适用版本

• OBServer：2.2.x
• 该问题与 NTP 同步机制相关，2.x、3.x、4.x 均可能遇到，具体阈值以 OCP 告警配置为准。

解决方法

应急处理：强制同步时钟

当发现 ntp_offset_milliseconds 已经很大（如超过 100 ms）时，建议立即强制同步，避免慢同步过程持续影响 OB。

使用 ntp 服务

# 使用 -b 参数强制步进同步，将 xxx.xxx.xxx.xxx 替换为实际 NTP 服务器 IP
ntpdate -b xxx.xxx.xxx.xxx

使用 chrony 服务

# 强制立即步进调整，要求 /etc/chrony.conf 中已配置可用时钟源
chronyc -a makestep

同步后，再次执行以下命令确认 offset 回到正常范围：

ntpstat
ntpq -p
# 或
chronyc sources -v
chronyc tracking -n

检查 OCP 及网络状态

1. 检查 OCP 服务器自身时钟是否正常。
2. 检查是否多个主机同时上报 host_ntp_offset_too_large：
   • 若只有单个主机上报，继续排查该主机的 NTP 服务及网络。
   • 若多个主机同时上报，优先确认 OCP 服务器或 NTP 服务器本身是否异常。
3. 检查故障主机与 OCP 服务器、NTP 服务器之间的网络是否正常：

ping
traceroute
clockdiff

4. 检查 NTP/Chrony 服务是否运行正常：

systemctl status ntpd
systemctl status chronyd

若服务异常，先修复服务再执行强制同步。

规避方式

• 预防措施：
  • 确保所有 OBServer 节点都配置了稳定可靠的 NTP 或 Chrony 时钟源。
  • 时钟同步服务设置为开机自启，并配置监控告警。
  • 避免 NTP 服务器单点，建议配置多个上游时钟源。
• 监控告警建议：
  • 对 host_ntp_offset_too_large 告警保持敏感，一旦超过 50 ms 即排查，不要等到 100 ms 停服阈值。
  • 对 ob_cluster_exists_inactive_server、OBServer 报文响应时间过长、OBServer 选举无日志等关联告警设置联动排查。
• 最佳实践推荐：
  • 部署前使用 clockdiff 检查所有 OBServer 节点之间的网络延迟，确保 ≤50 ms。
  • 定期巡检 NTP 偏移量，将其纳入日常运维检查项。
  • 跑批等高负载场景下，关注 observer.log 中 dump tenant info 相关日志，及时发现请求积压。
  • 若节点频繁因时钟问题被踢出集群，建议检查 NTP 服务器稳定性、网络质量以及虚拟机/物理机的时间同步配置。

参考文档

• host_ntp_offset_too_large 服务器与时钟源偏移过大
• 服务器与时钟源偏移过大。服务器与时钟源偏移过大，时钟偏移(367.613 毫秒)超过阈值(100 毫秒)。