查看原文
其他

你的Oracle RAC是真集群还是伪集群?高可用失效风险提醒

黄远邦 twt企业IT社区 2022-07-03
今天要和大家分享的是下面这么一个严肃的话题:
你的Oracle RAC是真的数据库集群么?还是一个伪集群呢?

换句话说:

当Oracle RAC集群中的一个节点所在的分区/服务器宕掉的时候,你是否可以和领导拍着胸脯说,“没事,这是ORACLE RAC,还有一个节点呢!只要该节点可以抗住负载,完全可以正常对外提供服务!”

如果你再把上面那段话读一遍,是否有开始犹豫的感觉了呢?

再换个方法来问一下这个话题:

虽然系统上线前做过RAC高可用测试,但是当集群中的一个节点长时间运行,包括CPU、内存、进程数在内的负载在不断变化,并且又经历了一些列变更后,期间又没有再做过高可用测试,这样的情况下,如果RAC一个节点所在的分区/服务器宕掉的时候,你是否依然可以拍着胸脯坚定的说,“我的Oracle RAC其他的节点一定可以正常对外提供服务!”?

同样的问题,当多了一些话语的铺垫后,再次听到这个问题的你,答案是否又更加犹豫了呢?

今天就为大家奉献一个“RAC高可用丢失”的真实案例其实完整、真实的分析过程。报告中将对Oracle数据库稳定运行的共性风险和隐患作出提醒。

分享本案例的意义:

估计不少朋友的系统中依然还存在类似的问题,建议参考本案例进行细致检查,排除隐患。如果有朋友反馈查到类似的隐患,那么就没有浪费笔者的一片苦心了。


本案例精彩看点:

这个案例会有不小的难度,客户为了分析该问题发生的根因,投入了大量的人力和时间,一度没有结果。笔者接手该case后,在缺少信息的情况下,问题的分析也一度陷入僵局。不过最终还是通过反复梳理所有线索,从一个和数据库毫不相关的小细节中找到了突破口,成功定位到了问题原因,实属不易。


1 故障描述

现象:Oracle RAC高可用丢失。表现如下:

1)下午16点1分左右,XX系统数据库RAC集群节点2所在的P595 发生硬件故障,导致节点2 数据库所在的分区不可用。

2)但从16点1分开始,应用程序无法连接到数据库RAC集群中存活的节点1。

ORACLE数据库RAC集群未能发挥高可用架构的作用!

客户指示,务必找到问题根因,以便对系统高可用架构提出改进意见。

笔者很理解,出了这样的大事,对于一个运行着几百套RAC的数据中心而言,是一个巨大的风险,其他系统是否也还存在这样的问题?什么时候会再发生?如果不找到问题根因,又如何做到由点带面全面全面梳理、检查和预防呢?

所以,接到该case时,还是有很大压力的。在开始分析前,得到了以下信息:

1)故障时运维DBA在RAC存活节点1通过sqlplus “/as sysdba”连接到数据库挂起

2)故障时运维DBA在RAC存活节点1通过sqlplus -prelim “/as sysdba”连接到数据库挂起,加了-prelim参数连接到数据库也hang,这是很罕见的情况

3)在存活的节点1上通过 crsctl stop crs -f停止crs无法停止,命令挂起无法结束

4)在存活的节点1上通过shutdown –Fr重启操作系统,命令挂起无法结束,最终通过hmc重启分区,业务恢复正常


2 分析过程

2.1 故障分析思路

集群中一个节点宕掉,其他节点无法对外提供服务。

通常情况下,是因为当中的集群软件没有完成对整个集群状态、数据的重组,
因此数据未达到一致,所以集群其他节点无法对外提供服务。

这个环境中部署在IBM小机上,其中用到的集群软件有:

ORACLE RAC/ORACLE CRS/IBM HACMP

因此,需要分别查看这三个集群是否完成了重组、重新配置

2.2 确认ORACLE RAC是否完成重组

查看一节点数据库alert日志,可以看到,RAC集群在16点1分32秒就完成了重组。

可排除该问题。

2.3 确认ORACLE CRS是否完成重组

可以看到,从16:01开始网络心跳超时,开始对节点2进行剔除的动作,最终在16:01:27节点2离开集群。可排除该问题。

2.4 确认IBM hacmp是否完成重组

经AIX专家分析,未发现HACMP中出现异常

整个检查下来,没有发现异常。

既然节点2数据库所在的Lpar宕了,那么节点2的vip应该会漂移到节点1上,接下来通过netstat –in命令检查,发现节点1上居然没有节点2飘过来的VIP !

接管VIP的动作最终将由CRSD进程来完成,因此检查CRSD.log,以便查看是否在接管过程中发生了什么异常。

2.5 检查1节点crs日志确认节点2 vip的接管情况

2.6 节点1 crs日志总结

可以看到:

1)节点2当掉后,节点1的CRS要把节点2的vip、db等资源接管过来,在节点1启动,但是调用脚本racgwarp来做check/start/stop时均出现了超时timeout,从而把子进程终止了。

2)并且节点1 本身自己的 vip检测中也出现了超时,如下所示

/oracle/app/oracle/product/10.2.0/crs/bin/racgwrap(check) timed out for ora.node1.vip! (timeout=60)

3) 因此,CRS在资源管理上也出现了一定的异常,主要是调用脚本racgwrap时出现了超时异常。

Racgwrap脚本出现timeout,通常是因为:

- 操作系统性能缓慢,如内存大量换页

- 脚本执行过程出现命令挂起的情况

2.7 检查nmon数据以获得操作系统性能

可以看到,5月20日的nmon居然停止在了故障时间点16点1分,这说明NMON执行到某个命令可能出现了挂起等异常

另外,从监控软件来看,操作系统未出现内存、CPU的告警。

2.8 确定分析方向

那么,接下来,我们的分析重点到底是放在数据库还是操作系统层面呢?

通过上面的线索梳理,我们有理由相信:

操作系统在当时出现了某些异常!因此后续把分析的重点方向放在操作系统层面!

2.9 汇总并梳理所有线索

1)存活节点Sqlplus –prelim无法attach到共享内存

2)Kill -9 无法杀掉部分进程

进程处于一个原子级的调用,例如一个IO,必须在两个调用之间才可以接受进程终止的信号,说明某个原子调用无法结束导致无法被kill -9终止

3)CRS通过脚本无法接管故障节点vip,出现超时

4)CRS通过脚本无法检测存活节点本身的vip/监听等资源,均出现超时

5)存活节点Nmon故障点后无输出

2.10 问题分析一度陷入僵局

虽然把方向放在操作系统上,但AIX专家未检查到异常。

AIX专家的结论是操作系统当时是没有异常的!

因为他们检查了一些crontab的脚本,是有输出的,说明OS还在工作。

如下图所示

2.11 如何找到突破口

笔者把方向定到了操作系统,但是操作系统专家检查并否认操作系统有异常。

对于存活节点nmon为什么停止写入的问题,双方持不同意见。

至此,问题分析陷入僵局,该如何继续往下分析呢?怎么能证明操作系统的异常呢?

1)如果没有给到操作系统一个明确的点,那么操作系统是很难查到到底有哪些异常的问题

2)问题分析陷入僵局,该如何找到突破口成为关键

3)坚信操作系统异常这个方向是正确的

回到原点,重新梳理和验证每个线索,会不会漏掉了什么重要线索

重新检查之前的线索,有重大发现!

可以看到:

从16点02分以及后续的的采样可以看到,到了” The file system result is as follows”的检测就停止了,没有写SYSTEM.SH_RUN_COMPLETE关键字来表示脚本执行完成.这说明操作系统在执行非数据库命令时也遇到了异常!

2.12 确认shell脚本出现异常时调用的具体命令

检查shell脚本,发现脚本挂在” The file system result is as follows:”的地方,事实上是调用了df命令来查看文件系统。

那么这个操作在什么情况会出现HANG的情况呢。

答案是使用nfs文件系统的时候。

XX系统数据库集群中使用了NFS文件系统,将节点2的/arch2文件系统通过NFS挂载到了节点1的/arch2文件系统上。当节点2出现硬件故障后,导致节点1无法与节点2的nfs server通讯,继而导致节点1上,df命令查看文件系统时挂起。

由此来看,节点1 nmon数据停止的原因是df命令hang住了

但是这和节点1无法连接数据库又有什么关系呢?

当笔者看到df命令时,泪奔了!

所有现象都可以得到解释了!当所有现象都得到解释的时候,心里就踏实了!这意味着你找到了问题的根因,那么预防措施就万无一失了!

2.13 Nfs mount点丢失和无法连接数据库的关系

执行连接数据库操作时,需要获取当前工作目录(pwd)

但是由于AIX某些版本操作系统内部实现pwd过程的缺陷,导致必须递归到根目录/下检查目录或文件的权限、类型.

当检查到nfs时,由于nfs 以hard/background方式挂载,当nfs server不可用时,必然导致检查nfs目录时出现挂起,继而导致了无法获得pwd的输出结果,继而导致无法连接数据库!

2.14 解开所有谜团

1) 存活节点Sqlplus –prelim无法attach到共享内存
获取当前工作目录时,由于nfs mount点丢失,get_cwd(pwd)挂起

2) Kill -9 无法杀掉部分进程
进程对nfs mount点进行IO操作,挂起,因此没有机会收到进程终止信号

3) CRS通过脚本无法接管故障节点vip,出现超时
Racgwrap脚本中调用了pwd命令

4) CRS通过脚本无法检测存活节点本身的vip/监听等资源,均出现超时
Racgwrap脚本中调用了pwd命令

5) 存活节点Nmon故障点后无输出
Nfs mount点丢失导致nmon调用df命令时挂起

2.15 再往前一步的分析

1.该机制下,如果根目录/小文件或目录很多,则pwd(get_cwd)的性能会很差

2.测试环境重现过程

节点2 mount /testfs到节点1的/testfs,停止节点2 nfs服务,未能重现。原因在于pwd的输出为/oracle, 首字母o比t要小,因此未检测到/testfs就获得pwd结果而退出了

节点2 mount /aa到节点1的/aa,停止节点2 nfs服务,未能重现。原因是通过truss命令对比,发现生产和测试环境检索/根目录下的行为不一致,继而检查OS版本,发现测试环境OS版本较高

3.高版本的OS无法重现,低版本的操作系统可以重现,说明操作系统做了修正和增强,在ibm.com上已nfs hang搜索,可以发现IBM发布了APAR来修复该问题


3 原因总结和建议

3.1 原因总结

RAC集群节点2所在的P595 发生硬件故障,导致节点2 LPAR不可用。继而导致Nfs mount点丢失。

登陆数据库时,需要获取当前工作目录(pwd)。

但是由于AIX某些版本操作系统内部实现pwd过程的缺陷,导致必须递归到根目录/下检查目录或文件的权限、类型。

当检查到nfs挂载点目录/arch2时,由于nfs 以hard/background方式挂载,当nfs server不可用时,必然导致检查nfs目录时出现挂起,继而导致了无法获得pwd的输出结果,继而导致无法连接数据库!

以hard/background挂载的NFS server丢失是导致RAC成为伪集群的根本原因!

所有故障现象都可以得到解释,如下:

1)存活节点Sqlplus –prelim无法attach到共享内存

获取当前工作目录时,由于nfs mount点丢失,get_cwd(pwd)挂起

2)Kill -9 无法杀掉部分进程

进程对nfs mount点进行IO操作,挂起,因此没有机会收到进程终止信号

3)CRS通过脚本无法接管故障节点vip,出现超时

Racgwrap脚本中调用了pwd命令

4)CRS通过脚本无法检测存活节点本身的vip/监听等资源,均出现超时

Racgwrap脚本中调用了pwd命令

5)存活节点Nmon故障点后无输出

Nfs mount点丢失导致nmon调用df命令时挂起

3.2 问题解决方案和建议

1) 如果需要实用nfs,则mount到二级目录,比如mount到/home /arch2而不是/arch2

2) 使用gpfs代替nfs

3) 提供故障线索时,请勿根据个人经验过滤掉认为不重要的信息

4) 安装AIX APAR,改变操作系统get_cwd(pwd)调用的内部实现方式

5)处理故障时Df命令hang的情况如果一开始就反馈,那么这个case直接就解开了,就不需要查了!

6)只在上线前做高可用测试是不够的,因为上线后系统会经历一系列的变更,可能某些因素会报纸RAC冗余性丢失,建议定期做高可用测试,可以选择在变更窗口选择逐个重启实例、服务器的方式来进行验证。


原题:我和数据中心的故事——Oracle RAC高可用失效风险提醒

作者:黄远邦(曾用笔名小y),就职于北京中亦安图科技股份有限公司,任数据库团队技术总监。长期活跃于国内多家银行总行生产数据中心,提供Oracle第三方服务,解决过无数疑难问题,在业内具有极佳的口碑。

本文地址:http://www.aixchina.net/Article/177843



长按下图二维码关注“AIX专家俱乐部”公众号

也可以直接搜索公众号名称“AIX专家俱乐部”或微信号“AIXChina”关注

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存