数据库集群自动重启?Linux硬件错误日志立大功!

社区广播:运维派(Yunweipai.com)是国内最早成立的IT运维社区,欢迎大家投稿,让运维人不再孤寂的成长!

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

一、故障问题现象

节点2频繁发生重启,从1月至2月发生多次重启,甚至一天内3次重启,让人头疼。

数据库集群自动重启

二、问题分析处理过程

1、检查是否时间同步问题

首先怀疑是时间不同步造成的。

观察现象是该服务器的ntp时间同步offset过大(下图offset为11376)

数据库集群自动重启

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

数据库集群

在这里发现一个问题,就是时间源指向旧的时间源服务器10.33.144.18和10.33.144.19,而服务器在新的数据中心,所以修改为新数据的时间源服务器11.8.13.1和11.8.13.9,并修改了BIOS时钟,使系统时钟和硬件时钟时间一致。

至此,时间同步问题排除。

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

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

数据库集群

又查CSSD日志发现

Linux 硬件

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

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

Linux 硬件

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

日志

4、检查是否是硬件的问题

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

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

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

MCELOG:不容忽视的日志

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

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

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

日志

ORACLE官方对MCELOG事件的解释:

Linux 硬件错误日志

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

三、问题总结与思考

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

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

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

文章出处:高效运维

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2017 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部