CRS-4535 根因是 CTSS 进入 observer mode，主因是节点存在 NTP 配置文件或 UTC 时间差超 500ms；需删除 /etc/chrony.conf 等文件、用 date -u +%s.%N 校验时间差、重启 ctssd 并观察 offset 稳定在 ±10ms 内。
CRS-4535 不是集群“挂了”，而是 CRS 进程没响应——最常见根因是 CTSS 退为 observer mode，或节点间时间差超阈值。
crsctl check crs 显示 CRS-4535 时，先确认 CTSS 状态
只要 crsctl check crs 返回 CRS-4535: Cannot communicate with Cluster Ready Services，别急着重启 crsd，先跑这句：
crsctl check ctss
如果输出是 CTSS is in observer mode，这就是确诊信号。说明 CTSS 主动放弃时间同步职责，不再参与集群仲裁，crsd 会随之拒绝启动或异常退出。
常见诱因包括：
- 任一节点残留
/etc/chrony.conf或/etc/ntp.conf（哪怕文件为空） - 节点间 UTC 时间差超过 500ms（用
date -u +%s.%N取三次平均再比对） -
ctssd进程僵死，但 PID 文件未清理，导致重启失败
检查节点时间差必须用 UTC 时间戳，不能只看 date 命令输出
date 显示的是本地时区时间，RAC 集群内部所有时间判断都基于 UTC。误用 date 会掩盖真实偏移。
正确做法是每个节点执行：
date -u +%s.%N
连跑三次，取平均值后计算最大差值。例如：
node1: 1730028601.123456789<br>node1: 1730028601.123457890<br>node1: 1730028601.123458901<br>→ avg: 1730028601.123457860<br><br>node2: 1730028601.654321098<br>node2: 1730028601.654322109<br>node2: 1730028601.654323120<br>→ avg: 1730028601.654322109<br><br>差值 = 0.530864249s ≈ 531ms → 已超安全阈值
超过 500ms 就该干预；超 1s 极大概率触发 ORA-00600 [kgxgncv1] 或直接驱逐节点。
删 NTP 配置文件比停服务更重要
Oracle 的判断逻辑非常刚性：只要 /etc/chrony.conf 或 /etc/ntp.conf 文件存在，CTSS 就强制 fallback 到 observer mode。
所以必须执行：
rm -f /etc/chrony.conf /etc/ntp.conf
而不是 systemctl stop chronyd 或 mv /etc/chrony.conf /etc/chrony.conf.bak——后者仍会被识别为“存在”。
删完后验证：
-
ps -ef | grep -E "(chronyd|ntpd)"应只剩 grep 自身进程 -
ls -l /etc/chrony.conf /etc/ntp.conf报“No such file”才安全 - 重启前手动清理
/var/run/chronyd.pid（如有）
重启 ctssd 后必须验证 offset 收敛性
删完配置、确认无残留进程后，不能指望 CTSS 自动恢复。必须人工重启并观察：
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 的 Active mode 不是“启动即稳”，而是需要收敛过程；没看到稳定 ±10ms 的 offset，就不能认为问题已解决。
