Oracle RAC要求节点间时间偏差≤500ms且禁止回跳，而默认chronyd配置未启用makestep和rtcsync，无法快速校正大偏移或防止重启后时间倒退，易触发CRS-4639等故障；必须配置iburst、minpoll/maxpoll、makestep 1.0 3、rtcsync等参数并验证tracking偏移。
oracle rac 对集群节点间时间偏差有严格要求：必须控制在 500ms 以内，且不能出现时间回跳。仅靠默认 chronyd 配置（尤其是未指定 `makestep` 或 `rtcsync`）大概率不满足生产 rac 要求。
为什么默认 chrony.conf 不适用于 Oracle RAC
RAC 节点若发生 >500ms 时间跳变（如系统重启后 NTP 首次校准），或存在持续 >1s 的偏移未被纠正，会直接触发 CRS 报错 CRS-4639、CRS-4000，甚至导致 OCR/Voting Disk 访问异常。默认配置中：
-
makestep默认注释掉，意味着大偏差时 chronyd 只会缓慢调整（slew），无法快速收敛 - 未启用
rtcsync，硬件时钟不同步会导致重启后时间大幅漂移 - 未限制最大校正范围（
makestep 1.0 -1中的-1表示无上限，但 RAC 实际要求单次 step ≤ 1s）
必须修改的 chrony.conf 关键项
编辑 /etc/chrony.conf，确保包含以下最小化安全配置（所有节点一致）：
server 192.168.10.1 iburst minpoll 4 maxpoll 6 driftfile /var/lib/chrony/drift makestep 1.0 3 rtcsync logdir /var/log/chrony log measurements statistics tracking
说明：
-
iburst：首次同步加速，减少初始偏移 -
minpoll 4 maxpoll 6：对应 16s–64s 同步间隔，比默认（64s–1024s）更敏感，适合 RAC 高精度场景 -
makestep 1.0 3：允许最大 1 秒阶跃校正，且仅对开机后前 3 秒生效（避免运行中突跳） -
rtcsync：强制内核将系统时间定期写入 RTC，防止重启后时间倒退
验证 chronyd 是否真正生效并满足 RAC 要求
改完配置后不能只执行 systemctl restart chronyd 就算完。必须确认三件事：
- 用
chronyc tracking检查System time偏移是否 Offset 和Root delay） - 用
chronyc sources -v确认已连接到预期 NTP 服务器，且状态为^*（优选源） - 用
chronyc makestep手动触发一次校准（仅限测试环境），再立刻chronyc tracking看是否进入 sub-500ms 区间 - 务必在所有 RAC 节点上分别执行
date; chronyc tracking | grep -E "(Offset|System time)"，横向比对结果
重启服务后仍不稳定的常见原因
即使配置正确、服务重启成功，仍可能因以下原因失败：
- 防火墙阻断 UDP 123 端口（检查
firewall-cmd --list-ports或iptables -L -n） - SELinux 强制模式下 chronyd 无法访问 NTP 服务器（临时设为 permissive 测试：
setenforce 0） - 节点使用了不同 NTP 源（如一个连内网 NTP，另一个连 pool.ntp.org），导致各节点时间基准不一致
-
/etc/adjtime文件残留旧的硬件时钟偏移参数，干扰rtcsync效果（可备份后清空该文件再重启 chronyd）
RAC 时间同步不是“配完就稳”，而是要持续监控 chronyc tracking 输出中的 Offset 波动幅度——稳定在 ±200ms 内才算真正达标。任何节点单次超 500ms，都应立即排查网络延迟或 NTP 源质量。
