如何处理RAC节点间时间差超过容忍度_节点驱逐保护机制与时间强同步

ctssd进入observer模式意味着CTSS因节点时间偏差过大（如超7分钟）而主动降级为只监控不校时状态，此时需排查chrony/ntpd配置并验证集群时间同步恢复。 ctssd 进入 observer 模式意味着什么 oracle rac 节点时间差一旦超出 ctss（cluster time synchronization service）的自动校正能力范围， 就会从 模式退为 模式——这不是故障告警，而是保护性降级。此时它不再尝试同步时间，只默默记录偏差，把校时责任让渡给外部机制（如 或 ）。你查 会看到 “ctss is in observer mode”，日志里则频繁出现类似 的记录（即约 7 分钟），这就是节点已被“静默隔离”的信号。 observer 模式下，RAC 不会立即驱逐节点，但已失去时间一致性保障，后续心跳超时、OCR 写入失败、ASM 磁盘组挂载异常都可能连锁发生 不要手动 kill 或强行 restart CRS——它退到 observer 是有原因的，硬拉回来只会反复失败 真正该看的是 ，重点找 “ ” 和 “ ” 关键字，确认偏差是否稳定、是否持续扩大 为什么不能直接用 date -s 强制调时间 在 RAC 环境中执行 是高危操作，尤其当两个节点时间差已接近或超过 15 秒时。测试表明：即使只是单节点向前调 10 小时，集群虽未当场崩溃，但 ASM 实例可能 hang 住、GCS（全局缓存服务）重传激增、甚至触发意外的节点驱逐（node eviction）。 RAC 内部大量依赖单调递增的时间戳（如 LMS 进程的 global enqueue 时间戳、GES 锁超时判断）， 造成的时间跳变会破坏这些逻辑 CTSS 在 active 模式下允许的最大平滑校正步长通常只有 ±1 秒左右；超过这个值，它就自动放弃，转为 observer 如果两个节点分别用 调整，哪怕只差几百毫秒，也可能导致 voting disk 写入冲突，引发 OCR 损坏风险 chrony 迭代同步比 ntpd 更适合 RAC Rocky Linux 9 默认用 不是偶然——它对大偏差（>1 秒）支持渐进式 slewing（平滑调整），而传统 在偏差 >1000 秒时默认拒绝同步，必须加 参数强制，这又带来跳变风险。RAC 要的不是“快”，而是“稳”和“可预期”。 配置 时，务必设置 ：表示对 ≤1 秒偏差走 slewing，>1 秒才允许一次性跳变（-1 表示无上限，但生产环境建议写成 ，即最多允许跳 100 秒） 所有 RAC 节点必须指向同一个内网 NTP 服务器（比如集群管理网段的专用 chrony server），禁止混用公网 NTP（延迟抖动大、不可控） 启动后用 确认 offset 在逐步收敛，用 确保所有节点连的是同一 source，且 stratum 一致 时间同步后必须验证的三件事 同步完成不等于问题结束。RAC 对时间敏感的组件有缓存、有状态、有延迟响应，必须人工确认关键链路已恢复。 检查 是否回到 模式；若仍是 observer，说明偏差未真正收敛，或 未自动重启（可手动 ） 查 ，确认没有连续出现 “ ” 或 “ ” 类错误 运行 （需 Grid Infrastructure 安装包），这是 Oracle 官方验证工具，能真实模拟集群心跳行为，比单纯看 差值更可靠 最容易被忽略的是：同步后没等 CTSS 自动恢复 active 模式就重启数据库实例，结果实例启动过程中因时间戳校验失败而卡在 “WAITING FOR CLUSTER READY SERVICES”——得再等几分钟，或者手动触发一次 。