事情发生在几个月之前，接到朋友电话，用户有三套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比较粗暴，发生故障时较大的时间偏差会导致应用出现问题，触发无法预知的后果。
收起