ctssd进入observer模式意味着CTSS因节点时间偏差过大（如超7分钟）而主动降级为只监控不校时状态，此时需排查chrony/ntpd配置并验证集群时间同步恢复。
ctssd 进入 observer 模式意味着什么
oracle rac 节点时间差一旦超出 ctss（cluster 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 更适合 RAC
Rocky Linux 9 默认用 chrony 不是偶然——它对大偏差（>1 秒）支持渐进式 slewing（平滑调整），而传统 ntpd 在偏差 >1000 秒时默认拒绝同步，必须加 -g 参数强制，这又带来跳变风险。RAC 要的不是“快”，而是“稳”和“可预期”。
- 配置
/etc/chrony.conf时，务必设置makestep 1.0 -1：表示对 ≤1 秒偏差走 slewing，>1 秒才允许一次性跳变（-1 表示无上限，但生产环境建议写成makestep 100 1，即最多允许跳 100 秒） - 所有 RAC 节点必须指向同一个内网 NTP 服务器（比如集群管理网段的专用 chrony server），禁止混用公网 NTP（延迟抖动大、不可控）
- 启动后用
chronyc tracking确认 offset 在逐步收敛，用chronyc sources -v确保所有节点连的是同一 source，且 stratum 一致
时间同步后必须验证的三件事
同步完成不等于问题结束。RAC 对时间敏感的组件有缓存、有状态、有延迟响应，必须人工确认关键链路已恢复。
- 检查
crsctl check ctss是否回到active模式；若仍是 observer，说明偏差未真正收敛，或ctssd未自动重启（可手动crsctl stop ctss; crsctl start ctss） - 查
tail -20 /var/log/oracle/crsd/ohasd.log，确认没有连续出现 “Time drift detected” 或 “Node evicted due to time skew” 类错误 - 运行
cluvfy comp clocksync -n all（需 Grid Infrastructure 安装包），这是 Oracle 官方验证工具，能真实模拟集群心跳行为，比单纯看date差值更可靠
最容易被忽略的是：同步后没等 CTSS 自动恢复 active 模式就重启数据库实例，结果实例启动过程中因时间戳校验失败而卡在 “WAITING FOR CLUSTER READY SERVICES”——得再等几分钟，或者手动触发一次 crsctl start ctss。
