如何进行rac节点频繁重启的问题分析

如何进行rac节点频繁重启的问题分析，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

环境：两台联想R680的物理机搭建一套2节点RAC，数据库版本为ORACLE 11.2.0.4

一、故障问题现象：
节点2频繁发生重启，从1月至2月发生多次重启，甚至一天内3次重启，让人头疼。

二、问题分析处理过程：

1、时间同步问题
首先怀疑是时间不同步造成的。
观察现象是该服务器的ntp时间同步offset过大

并在数据库的CTSS日志出现不正常的返回值

在这里发现一个问题，就是时间源指向旧的时间源服务器，而服务器在新的数据中心，所以修改为新数据中心的时间源服务器并修改了BIOS时钟，使系统时钟和硬件时钟时间一致。至此，时间同步问题排除。

2、数据库日志反应的问题

通过查ALERT日志，发现有节点驱逐

又查CSSD日志发现

显示有磁盘的心跳，但无网络的心跳。

此时判断：node 2 节点老是频繁重启，私网出问题的概率会较大，因此从网络处查。node 2 每次重启完以后，都能顺利加入rac集群，更不是时间同步的问题。 

补充：

如果集群中的节点连续丢失磁盘心跳或网络心跳，该节点就会被从集群中驱逐，也就是节点重启。组管理导致的节点重启，我们称之为node kill escalation（只有在11gR1以及以上版本适用）。重启需要在指定的时间（reboot time,一般为3秒）内完成。

网络心跳:ocssd.bin进程每秒钟向集群中的各个节点通过私网发送网络心跳信息，以确认各个节点是否正常。如果某个节点连续丢失网络心跳达到阀值，misscount（默认为30秒，如果存在其他集群管理软件则为600秒），集群会通过表决盘进行投票，使丢失网络心跳的节点被主节点驱逐出集群，即节点重启。如果集群只包含2个节点，则会出现脑裂，结果是节点号小的节点存活下来，即使是节点号小的节点存在网络问题。

磁盘心跳：ocssd.bin进程每秒钟都会向所有表决盘（Voting File）注册本节点的状态信息，这个过程叫做磁盘心跳。如果某个节点连续丢失磁盘心跳达到阀值disk timeou(一般为200秒)，则该节点会自动重启以保证集群的一致性。另外，CRS只要求[N/2]+1个表决盘可用即可，其中N为表决盘数量，一般为奇数。

3、核查网络的问题

这套RAC的心跳网是由ETH13和ETH15两块网卡组成，对应两个交换机的两个端口。

先后采取激活宕掉交换机两个端口和网卡口没有解决问题，最后又采用换线、单独拉线等解决办法，发现线的光衰有点大，但重启问题没有最终解决。

4、是否是硬件的问题？

问题至此陷入了困境，换个思路既然网络和数据库都可能不是问题，那么硬件真的能独善其身，超然之外么？

答案是否定的，那就是硬件的问题。

在节点发生重启时，数据库的日志里有中断的现象，那么会不会是CPU和内存的问题呢？检查下MCELOG日志就知道了。

MCELOG不容忽视的日志

mcelog 是 x86 的 Linux 系统上用来检查硬件错误，特别是内存和CPU错误的工具。它的日志就是MCELOG.

一般来说大内存的服务器容易出现内存上的问题，现在内存控制器都是集成在cpu里，内存的校验错误和CPU的问题易引起服务器的重启。

至此，问题浮出水面。和硬件厂商联系，刷主板固件程序，更换一根内存后问题最终解决。

三、问题总结与思考：

1、不能忽视监控的作用。这次内存硬件的问题，在服务器硬件监控平台没有被发现，这个需要联系厂商，继续完善服务器硬件监控的细粒度和敏感性

2、从日志、网络、数据库、系统、硬件等方面全面排查，问题终会被发现。

3、解决问题靠的是耐心和细心，进一步再进一步，问题终会被解决。

看完上述内容，你们掌握如何进行rac节点频繁重启的问题分析的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！