ctssd退为observer mode是最直接的稳定性杀手：一旦检测到/etc/ntp.conf或/etc/chrony.conf存在（即使为空或重命名），ctssd即强制降级，不再自主同步，仅旁观外部时间服务；而默认NTP/chronyd配置无法满足RAC≤500ms偏差且禁回跳的要求，导致时间差扩大，最终触发ORA-00600[kgxgncv1]或实例启动失败。
ctssd 退为 observer mode 是最直接的稳定性杀手
Oracle RAC 的时间同步核心是 ctssd 进程，它默认在无外部 NTP 干扰时进入 Active mode，自主选举参考节点并做毫秒级微调。一旦系统检测到 /etc/ntp.conf 或 /etc/chrony.conf 存在（哪怕内容为空、被重命名），ctssd 就强制降级为 observer mode——此时它不再控制时间，只“旁观” NTP/chronyd 工作。但多数默认配置根本达不到 RAC 要求，结果就是：时间差缓慢扩大，直到触发 ORA-00600 [kgxgncv1] 或实例拒绝启动。
默认 chronyd/ntpd 配置无法满足 RAC 的硬性指标
RAC 要求节点间偏差 ≤ 500ms 且禁止时间回跳。而默认 chronyd 或 ntpd 配置存在三个致命短板：
-
makestep被注释：大偏移（如重启后）只能缓慢 slewing 调整，可能数小时都超 500ms - 未启用
rtcsync：系统重启时硬件时钟未同步，导致开机瞬间时间倒退或大幅漂移 -
minpoll/maxpoll过宽（默认 64s–1024s）：同步间隔太长，无法及时响应网络抖动或瞬时漂移
这些缺陷会直接引发 CRS-4639、CRS-4000，甚至 OCR/Voting Disk 访问异常。
混用或配置不一致比完全不用更危险
运维中常见错误包括：部分节点启 chronyd、部分停着；一个节点删了 /etc/ntp.conf、另一个留着空文件；或用 ntpdate -s 手动校时。这些操作看似“修好了时间”，实则让 ctssd 在各节点状态分裂——有的 active、有的 observer，集群内部心跳和 cache fusion 依赖的时序逻辑彻底紊乱。日志里频繁出现 Failed to communicate with reference node 或 Msg NOT meant for this member 就是典型表现。
防火墙与服务残留常被忽略
即使配置写对了，以下问题仍会导致同步失效：
- UDP 端口 123 被防火墙拦截：
firewall-cmd --list-ports检查是否放开 - 残留
ntpd或chronyd进程未 kill 干净：ps -ef | grep -E "(ntpd|chronyd)"必须只看到 grep 自身 -
/var/run/chronyd.pid或/var/run/ntpd.pid文件未删，导致服务重启失败 - 修改
/etc/chrony.conf后只执行systemctl restart chronyd，却没验证chronyc tracking输出的Offset是否真正收敛
真正关键的不是“配了 NTP”，而是所有节点的 ctssd 状态统一、chronyc tracking 显示的 System time 偏移稳定在 ±10ms 内，且持续观察无跳变——这点最容易被跳过。
