暂无图片
暂无图片
1
暂无图片
暂无图片
暂无图片

RAC一个节点自动重启问题分析

曾天水 2016-12-02
516

题记:在RAC数据库的故障当中,节点重启的现象很常见,在这种问题的处理当中,有一定的规律性。为了更好的说明这个问题的处理过程,保证出现该类问题的时候,能够有序的进行处理,特编写此文档

作者介绍


曾天水水哥) , oracle认证大师,在数据库领域钻研了10多年,擅长数据库优化,系统架构方案设计,疑难杂症问题解决等,并在开源领域也有广泛的涉猎。


问题现象描述

此问题的现象比较明显,也就是数据库自动重启,或者是节点自动重启,客户端在数据库重启期间无法连接数据库,导致业务断连的现象。这种情况如果出现在业务高峰期间,将会对业务造成较大的影响,所有连接到重启节点的用户将断开,系统压力全部转移到健康节点,如果另外一个节点无法支撑较大压力的时候,那么业务将全部中断,因此,需要对此类问题进行重视,并理解此类问题的一个处理思路!


问题处理思路

遇到此类问题的发生,需要一个明确的思路,特别是当故障发生比较紧急时候,需要快速的定位故障原因,快速的解决问题。

(1)首先需要进行问题定位

通过命令检查操作系统的启动时间:Uptime

通过命令检查数据库启动的时间:

Select start_time from v$instance;

检查后台日志,看有没有实例重启的日志;

        

诊断节点重启问题是经常搜集的信息。

  • 操作系统日志;

  • <crs主目录>/log/<节点名称>/cssd/ocssd.log;

  • oprocd.log(/etc/Oracle/oprocd/*.log.*或 var/opt/oracle/oprocd/*.log.*);

  • <crs主目录>/log/<节点名称>/cssd/oclsomon/oclsomon.log;

  • <oracle 主目录>/log;

  • OracleOSWatcher 报告;

      

如果上述条件满足,那么可以确定和本文档相符,可继续往下处理。


(2)接下来我们讨论如何诊断节点重启问题。

-->由ocssd导致的节点重启。

如果在ocssd.log中出现以下错误,则表示节点重启是由于丢失网络心跳。接下来需要查看和网络相关的信息,如操作系统日志,OSW报表(traceroute的输出),以确定网络层面(cluster interconnect)是否存在问题,并确定最终的原因。


注意:如果在主节点的ocssd.log中出现以上信息的时间点要晚于节点的重启时间,则说明节点重启的原因不是丢失网络心跳。


如果ocssd.log中出现以下错误,则表示节点重启是由于丢失磁盘心跳。接下来需要查看操作系统日志,OSWatcher报告(iostat的输出),以确定i/o层面是否存在问题,并确定最终的原因。


-->由oclsomon导致的节点重启。

如果在oclsomon.log 中出现错误,则表示节点重启是由于ocssd进程挂起,由于ocssd进程拥有实时(RT)优先级,很可能此时操作系统存在资源(如cpu)竞争,接下来需要察看操作系统日志,OSW报表(vmstat,top的输出),以确定最终的原因。


-->由oprocd导致的节点重启。

如果在oprocd日志中出现以下信息,则表明节点重启是由oprocd进程导致。

Dec 21 16:15:30.369857 | LASTGASP | AlarmHandler:  timeout(2312msec) exceeds interval(1000 msec)+margin(500 msec).   Rebooting NOW.


由于oprocd进程通过查看系统时间以确定操作系统是否挂起,正确的配置ntp(或其他时间同步软件),调整diagwait=13 可以避免节点重启,另外,如果需要大幅度修改系统时间,建议首先停止CRS,在修改完成之后再重新启动。当然,我们也不排除操作系统挂起导致oprocd重启节点,所以,也需要查看OSWatcher报告(vmstat,top的输出),以确定最终的原因。


-->由安装问题导致的节点重启。

Oracle数据库集群的安装,官方文档都已经详尽的说明了如何配置数据库,如何配置集群,如何配置主机,如何配置网络,需要哪些补丁。这些必需的条件如果在安装的过程中没有正确配置,也许在某一天的节点重启中,无法准确确定问题的起因的时候,它就是罪魁祸首。


相关理论知识介绍

首先我们对能够导致节点重启的CRS进程进行介绍:

1、ocssd : 它的主要功能是节点监控(Node Monitoring)和组管理(GroupManagement),它是CRS的核心进程之一。节点监控是指监控集群中节点的健康,监控的方法是通过网络心跳(network heartbeat)和磁盘心跳(disk heartbeat)实现的,如果集群中的节点连续丢失磁盘心跳或网络心跳,该节点就会被从集群中驱逐,也就是节点重启。组管理导致的节点重启,我们称之为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为表决盘数量,一般为奇数。


2、oclsomon:这个进程负责监控ocssd是否挂起,如果发现ocssd.bin存在性能问题,则重启该节点。


3、oprocd:这个进程只在Linux和Unix系统,并且第三方集群管理软件未安装的情况下才会出现。如果它发现节点挂起,则重启该节点。

注意:以上的所有进程都是由脚本init.cssd产生的。


故障处理案例分析

经过数据库故障磨炼的兄弟都知道,数据库是一个综合体,它的每一次故障都涉及到方方面面,比如网络,系统,存储,应用等等。如果把数据库作为一个独立体处理,也许在故障处理的过程中,就失去了扩展的思维,把自己禁锢在某个点,而无法突破。只有把数据库看作一个整体,你才有那种众里寻他千百度,蓦然回首,却在灯火阑珊处的感觉!

 这个时候,时间定格在2012年7月7日,这时候,突然电话铃响,紧急报障,某数据库节点一发生重启,故障就是命令,事不宜迟,登录数据库查看相关信息。

信息也比较明显:

[cssd(3539304)]CRS-1611:nodecs_02 (0) at 75% heartbeat fatal, eviction in 0.000 seconds


也就是心跳超时,导致节点重启。既然是心跳超时,那么有两种原因:一种原因是心跳磁盘无法连接,另一种是是心跳网络无法连接。首先去查证心跳磁盘有没有问题:

$ crsctl query css votedisk

 0.     0    /dev/rvotedisk1

 1.     0    /dev/rvotedisk2

 2.     0    /dev/rvotedisk3

located 3 votedisk(s).


从这里可以看出,心跳磁盘正常访问,没有异常。那就是网络了,由于没有部署相关的网络监控软件,此时无法确定网络什么时候出了异常,断链情况如何,于是部署OSW软件,并且在后台部署长ping命令:

On Node1:

traceroute -s 192.168.65.234-r  192.168.65.235  1472

ping -s 1500 -c 2 -I192.168.65.234 192.168.65.234

ping -s 1500 -c 2 -I 192.168.65.234192.168.65.235

On Node2:

#traceroute -s 192.168.65.235-r  192.168.65.234 1472

ping -s 1500 -c 2 -I192.168.65.235 192.168.65.235

ping -s 1500 -c 2 -I192.168.65.235 192.168.65.234)


时间又在飞逝,系统不知道是不是知道我们布好了天罗地网,也不重启了,大家都以为相安无事,也渐渐淡忘,唯有我们数据库最后的保护者,还是一直在关注着,因为我们知道,这是我们的责任,这是DBA的一种执着的责任,对客户的负责,对数据库的负责。


终于这天来到了,2012年8月1日,这家伙终于不老实了,再次发生重启。我们有条不紊的进入数据库,按部就班的搬出我们的网,看看捕到了什么大鱼。首先,还是检查日志,和上次重启一样,是发生脑裂,剔除节点;然后检查系统层面,没有任何报错,排除硬件原因引起的重启;最后用我们部署的脚本,找到了相关的蛛丝马迹:


从这里我们可以看到,交换机的信息出现混乱,从末数据库的主机的端口接收到了其它IP的包信息。


查看OSW信息:


发现在故障期间,主机资源都算比较充足,因此可以排除由于主机负载引起的脑裂重启。

那会不会是系统或者是DRM配置的问题呢,因为在我们接触的案例中,有这种问题,于是进行相关整改:

  • 通过关闭DRM设置,目前DRM是打开的;

  • oraclebug,Bug 5190596  LMON dumps LMS0 too often during DRM leading to IPC sendtimout

  • aix6.1没有打补丁,Block Lost or IPC Send Timeout PossibleWithout Fix of APAR IZ97457


整改完成后,数据库再次稳定,这个时候,时间已经到达2012年8月14日,很不幸的消息,从14日开始,连续发生多次重启,越来越频繁的重启,牵动着每一位参与此故障处理的同事们的心,就像是自己的孩子,一次又一次被人家欺负,而我们又只能远远看着。


时间来到8月20日,这段时间也经历了一个插曲,两个节点的操作系统版本竟然不一致,于是矛头也曾经指向了它,但是进行操作系统内核升级后,节点还是多次出现重启。终于,经过这么长时间的排查和摸索,最终将问题定位在网络上。有了大家一致认定的方向,剩下的就是排查了,首先指向的就是交换机,因为此交换机是多部主机共用,而且是同一个vlan,这在实际运用中,是比较大的隐患。


后续网络的同事发现原交换机配置错误,同一个IP段划分了2个VLAN,VLAN1用于某数据库系统,VLAN100用于某应用系统的心跳,导致数据包异常。(其实这个不是原因,当时网络同事想改了后,再换回来,想不通过换交换机的方式,但是我们坚持要换,所以才查出是交换机的问题,如果当时没换,改完之后还是有问题,估计又得折腾了,而且是折腾我们自己,遇到网络问题的时候,能最小化问题,就最小化问题)。从后面处理的过程就可以看出,后来重新换回交换机后,先后通过调整心跳交换机配置、停止IBM的DHCP server、恢复交换机出厂配置操作,问题依然没有解决,而且后续的日志也更有欺骗性:


2012-09-0701:34:08.928

[cssd(3539304)]CRS-1605:CSSDvoting file is online: dev/rvotedisk1. Details in/u01/oracle/product/10.2/crs/log/cs_01/cssd/ocssd.log.

2012-09-0701:34:08.931

[cssd(3539304)]CRS-1605:CSSDvoting file is online: dev/rvotedisk2. Details in/u01/oracle/product/10.2/crs/log/cs_01/cssd/ocssd.log.

更换交换机后,节点再没有重启,至此,耗时60天的主机重启问题,终于得到圆满的解决。


回顾整个故障的处理过程,走过了不少的弯路,从主机,存储,网络,数据库

各个层面进行了多层次的分析,一步一步的走近答案。在这个过程中,有着永不放弃精神,有着责任心,最终抽丝剥茧的找到了问题的最终答案。


后记

作为一个合格的DBA,必须拥有丰富的知识,冷静的头脑和解决问题的思路;

DBA这个职业并不像是圈外人士想象的就是钱多事少的职业;

DBA应该是这种状态,当你维护的数据库健康稳定的运作,当最终用户由衷的赞叹:这个查询真快的时候,我们会心的一笑;

作为一个DBA老兵,我们应该有那种心里的感觉,当处理完每一次故障的时候,蓦然回首的时候,它却在灯火阑珊处……


如何加入"云和恩墨大讲堂"微信群

搜索 盖国强(Eygle) :eyygle,或者扫描下面二维码,备注:云和恩墨大讲堂,即可入群。每周与千人共享免费技术分享,与讲师在线讨论。


近期文章

MySQL Group Replication 学习笔记

利用硬链接和truncate降低drop table对线上环境的影响

以12c Identity类型示范自我探索式学习方法

从执行计划洞察ORACLE优化器的“小聪明”

Oracle安全比特币勒索问题揭秘和防范

针对Sharding DB的单点故障,合理构建HA架构

资源下载

(OraNews)回复关键字获取

CodeSet,《Oracle性能优化与诊断案例精选》代码;

2016OTC,第六届Oracle技术嘉年华PPT;

2016DTCC, 2016数据库大会PPT;

DBALife,"DBA的一天"精品海报大图;

12cArch,“Oracle 12c体系结构”精品海报;

DBA01,《Oracle DBA手记》第一本下载;

YunHe“云和恩墨大讲堂”案例文档下载;

文章转载自曾天水,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论