oracle系列03-关于OracleRAC ntp问题的解决一例

背景：

我的生产环境是一套19C CDB/PDB架构的4节点RAC，由于是中途接手的维护项目，在自身运行正常的情况下，没有过多考虑NTP时间同步问题。但近期由于中心NTP服务器异常，从而牵扯出一系列的问题。

26日早晨接到多个应用的反馈，前端时间显示跟实际差了八九个小时。有些对实际敏感的应用已经宕机。立刻把问题定位到中心的几台NTP服务器上。

中心NTP架构：

NTP客户端（部分应用）-----二级NTP服务器（小范围使用）---一级NTP服务器------阿里外网NTP 

oracleRAC所有服务器的上级NTP指向了二级NTP服务器。

排查思路：

由于业务影响面很大，基本涵盖了所有的NTP服务器的辐射范围。

我先登录二级NTP，查看NTP状态如下：

我刚开始冷一看，以为就是状态二级NTP服务器的问题，结果仔细查看相关资料发现，NTP服务failed的主要原因是跟上级NTP服务器时钟超出了1000s，NTP服务自动停止。这个问题其实主要就是跟上级NTP服务同步时间异常所致。这里的具体解决方案，在后面解决方案中描述。

然后我再一次看一级NTP服务器，发现跟阿里的时间服务器无法同步。网络都通，但跟阿里的NTP交互不正常。

经此最终找到问题，将NTP服务重新部署。解决了所有问题。

在业务都恢复正常后，我才详细关注了一下我的RAC集群的NTP问题。

我发现我的RAC集群的所有节点都配置了NTP，将上级NTP指向了中心的二级服务器。然后所有的节点出现的故障也和上面一样，所有的NTP服务都failed了。

然后，集群alert日志中报了很多时间偏移的问题，这应该是NTP不正常导致的集群的日志。

通过以上发现，集群可能需要整体重启一遍了。参考其他人的文档：

oracle数据库因一次服务器时间调整引发的实例宕机注意事项及解决方案

在时间调整的过程中，建议集群在关闭的情况下进行。

关于便宜1000s NTP服务宕掉的问题，大家可以按如下方法操作，这样的好处就是即便偏移1000s，ntp同样提供服务，不会启动失败。

在配置文件/etc/ntp.conf中增加一行：

tinker  panic  0
使ntp在时间差较大时依然工作

同时，一般建议ntpdate -u ip 的时候，也同时执行一个hwclock -w 将系统时间同步给硬件时间，这种方式在物理机的情况下，尤其有用，可以防止很多不必要的时间问题。

具体实现思路：

编辑自动同步脚本：
vim /usr/local/sbin/ntpdate.sh

#!/bin/bash

export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin"

ntpdate -u 192.168.149.150

hwclock -w

#crontab -e

* * * * * /usr/local/sbin/ntpdate.sh >> /tmp/ntp.log  # 如：每分钟同步一次

具体NTP服务配置，可以参考如下连接，这篇文章写的比较实际了。

linux时间同步，ntpd、ntpdate - 哦吼厉害哟 - 博客园