rac节点频繁重启的问题分析

时间:2022-03-25 09:25:24


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

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

rac节点频繁重启的问题分析


二、问题分析处理过程:

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

rac节点频繁重启的问题分析

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

rac节点频繁重启的问题分析


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


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

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

rac节点频繁重启的问题分析

又查CSSD日志发现
rac节点频繁重启的问题分析


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

此时判断: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的心跳网是由ETH13ETH15两块网卡组成,对应两个交换机的两个端口。

rac节点频繁重启的问题分析


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

rac节点频繁重启的问题分析


4、是否是硬件的问题?

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

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

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

 

MCELOG不容忽视的日志

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

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


好了,下面我们看看MCELOG日志的错误提示

rac节点频繁重启的问题分析

ORACLE官方对MCELOG事件的解释:

rac节点频繁重启的问题分析


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


三、问题总结与思考:

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

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

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


本文出自 “滴水穿石孙杰” 博客,转载请与作者联系!