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

题记:在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老兵,我们应该有那种心里的感觉,当处理完每一次故障的时候,蓦然回首的时候,它却在灯火阑珊处……

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-12-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏大宽宽的碎碎念

聊聊BIO,NIO和AIO (2)磁盘IO磁盘IO的优化AIO反思AIO

4538
来自专栏ImportSource

微服务应具备的12个属性

该文翻译自Pivotal公司的 Matt Stine大牛的书籍《Migrating to Cloud Native Application Architectu...

2619
来自专栏杨建荣的学习笔记

数据迁移前的准备和系统检查 (r2笔记70天)

关于数据迁移,在之前也讨论过一些需要注意的地方,可能林林总总列了不少,都是在数据迁移迁移前和迁移时需要注意的。 http://blog.itpub.net/23...

2554
来自专栏许健的专栏

Python 多线程的思考

在知乎等地方经常看到有人问,Python 的多线程是不是鸡肋?为何我用多线程性能一点没有提升,有时候性能反而下降?在这里通过日常工作中遇到的问题以及自己的一些总...

3340
来自专栏微信终端开发团队的专栏

微信终端跨平台组件 Mars 系列(三):连接超时与 IP & Port 排序

Mars 系列开始,将为大家介绍 STN(信令传输网络模块)。由于 STN 的复杂性,该模块将被分解为多个篇章进行介绍。本文主要介绍微信中关于 socket 连...

4450
来自专栏禁心尽力

如何在分布式环境中同步solr索引库和缓存信息

     搜索无处不在,相信各位每天都免不了与它的亲密接触,那么我想你确实有必要来了解一下它们,就上周在公司实现的一个小需求来给各位分享一下:如何在分布式环境...

2099
来自专栏北京马哥教育

MySQL 高性能优化实战全解!

MySQL对于很多Linux从业者而言,是一个非常棘手的问题,多数情况都是因为对数据库出现问题的情况和处理思路不清晰。在进行MySQL的优化之前必须要了解的就...

3679
来自专栏沃趣科技

ASM 翻译系列第十四弹:ASM Internal Rebalancing act

原作者:Bane Radulovic 译者: 吴 栋 审核: 魏兴华 DBGeeK社群联合出品 Rebalancing act 在ASM中,每...

3375
来自专栏Laoqi's Linux运维专列

浅谈web网站架构演变过程

1404
来自专栏恰同学骚年

《大型网站技术架构》读书笔记之六:永无止境之网站的伸缩性架构

此篇已收录至《大型网站技术架构》读书笔记系列目录贴,点击访问该目录可获取更多内容。

572

扫描关注云+社区