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