事情发生在一段时间之前，接到朋友电话，用户有三套 oracle rac 集群运行在 aix 小机上，本地两套，同城机房两套，做完设备搬迁后的一天晚上，其中本地和同城的两套 rac 突然就整个重启了，而且发生在同一时间点。

网络、小机、存储、数据库分属不同的维保厂商，这就开始了扯皮。各家就开始从自己的方向自证无过错。我去之前内心也比较倾向于 oracle 的网络心跳出了问题，crs 抢 vote disk 的时候触发了重启。但由于是小机方的代表，仅从 aix 层面做了排查，未发现明显原因。对各主机宕机的时间做了一个梳理，去和 oracle 的事件日志去比对。暂时没查到什么东西。

宕机产生的 dump 发到了 IBM 原厂，IBM 后来出了个报告，根据 dump 内容定位触发宕机的进程为 cssd。oracle dba 重点看了那个进程的日志，发现宕机时间前后，时间突然变更，提前了40多秒。dba 确认，时间变更过多，cssd 进程会导致系统重启，怀疑和时间同步有关。

经检查，3套 aix 的 rac 集群使用了同一个 ntp server，但有一套没发生问题。对比检查差异，发现没问题的那套主机集群使用 xntpd 方式配置了时间同步。出问题的主机则直接使用了 ntpdate 命令做时间更新，并写入了 crontab 定期执行。检查 /var/adm/cron/log 日志，发现定时任务的执行时间和 cssd 故障时间一致。检查时间服务器，发现搬迁后，时间服务器的时间产生了较大偏差，xntpd 方式的时间同步在时间偏差大时不会去强制同步，ntpdate 命令的方式没有这个限制，会直接进行同步。最终导致了 cssd 进程检测到过大时间偏差后触发了宕机。

经验分享：配置时间同步时，建议使用 xntpd 服务的方式，不用直接在定时任务里写 ntpdate，因为 ntpdate 比较粗暴，发生故障时较大的时间偏差会导致应用出现问题，触发无法预知的后果。