oracle 19c rac节点时间不同步不会直接导致集群异常退出，但会触发ctss退为observer mode，进而引发实例终止、crs启动失败或节点驱逐；crsctl check ctss显示observer mode是确诊依据，需立即清理ntp配置文件、重启ctssd并验证offset稳定在±10ms内。
Oracle 19c RAC节点间时间不同步不会直接“导致集群异常退出”，但会触发CTSS退为observer mode，进而引发实例终止、CRS启动失败或节点被驱逐——这些现象常被误认为“异常退出”，实则是集群主动保护机制在起作用。
crsctl check ctss 显示 observer mode 就是核心信号
这不是警告，是确诊依据。只要执行crsctl check ctss返回CTSS is in observer mode，说明CTSS已放弃同步职责，正依赖外部服务（但往往并不可靠）。此时：
- 所有节点必须立刻执行
date -u +%s.%N取三次平均，计算最大差值；超过500ms即高风险，超1s大概率触发ORA-00600 [kgxgncv1]或CRS-4535 - 查
$GRID_HOME/log/`hostname`/ctssd/ctssd.log，重点找Switching to observer mode或Failed to communicate with reference node - 哪怕只有一台节点残留
/etc/chrony.conf或/etc/ntp.conf（哪怕文件为空），CTSS就会全局fallback
为什么删配置文件比停服务更重要
Oracle判断逻辑极死板：文件存在 = NTP启用 = CTSS必须让权。很多修复失败，是因为只做了systemctl stop chronyd，却漏删了配置文件：
-
mv /etc/chrony.conf /etc/chrony.conf.bak仍会被识别为“存在”，必须rm -f /etc/chrony.conf /etc/ntp.conf - 删完后必须确认
ps -ef | grep -E "(chronyd|ntpd)"只剩grep自身进程 - 重启
ctssd前不清理PID文件（如/var/run/chronyd.pid）会导致服务无法真正释放端口或资源
重启 ctssd 后 offset 必须稳定在 ±10ms 内
清理完NTP残留后，CTSS不会自动切回Active mode，必须人工干预并验证收敛性：
- 执行
crsctl stop res ora.ctssd -init && crsctl start res ora.ctssd -init - 等2–3分钟，再跑
crsctl check ctss：正常应返回CTSS is in Active mode和类似Offset (in msec): 7的数值 - 用
watch -n 10 'crsctl check ctss'持续观察10分钟，确保offset无跳变、波动始终在±10ms内 - 若仍显示
observer，立即检查是否某节点漏删了/etc/chrony.conf（尤其容易忽略）
真正难处理的不是时间差本身，而是CTSS状态切换的隐式依赖：它不报错、不阻塞启动，却让整个集群失去自适应同步能力，时间差会持续扩大，最终在某个临界点突然崩塌——这个过程往往没有明显日志预警，只有事后回溯才能定位到最初那个被忽略的observer mode提示。
