前言
小y今天要和大家分享的是下面这么一个严肃的话题:
你的Oracle RAC是真的数据库集群么?还是一个伪集群呢?
换句话说:
当Oracle RAC集群中的一个节点所在的分区/服务器宕掉的时候,
你是否可以和领导拍着胸脯说,
“没事,这是ORACLE RAC,还有一个节点呢!只要该节点可以抗住负载,完全可以正常对外提供服务!”
如果你再把上面那段话读一遍,是否有开始犹豫的感觉了呢?
小y再换个方法来问一下这个话题:
虽然系统上线前做过RAC高可用测试,但是当集群中的一个节点长时间运行,包括CPU、内存、进程数在内的负载在不断变化,并且又经历了一些列变更后,期间又没有再做过高可用测试,这样的情况下,如果RAC一个节点所在的分区/服务器宕掉的时候,你是否依然可以拍着胸脯坚定的说,“我的Oracle RAC其他的节点一定可以正常对外提供服务!”?
同样的问题,当多了一些话语的铺垫后,再次听到这个问题的你,答案是否又更加犹豫了呢?
小y今天就为大家奉献一个“RAC高可用丢失”的真实案例及其完整、真实的分析过程。
了解到导致Oracle RAC高可用失效的一些具体因素。
小y估计不少朋友的系统中依然还存在类似的问题,
建议参考本案例进行细致检查,排除隐患。
。
案例精彩看点预告
Part 1
故障描述
现象:Oracle RAC高可用丢失。表现如下
1)下午16点1分左右,XX系统数据库RAC集群节点2所在的P595 发生硬件故障,导致节点2 数据库所在的分区不可用。
2)但从16点1分开始,应用程序无法连接到数据库RAC集群中存活的节点1。
ORACLE数据库RAC集群未能发挥高可用架构的作用!
客户指示,务必找到问题根因,以便对系统高可用架构提出改进意见。
小y很理解,出了这样的大事,对于一个运行着几百套RAC的数据中心而言,是一个巨大的风险,其他系统是否也还存在这样的问题?什么时候会再发生?如果不找到问题根因,又如何做到由点带面全面全面梳理、检查和预防呢?
环境描述:
AIX 5.3
Oracle 10.2 2节点 RAC
HACMP+裸设备
所以,小y接到该case时,还是有很大压力的。在开始分析前,小y得到了以下信息:
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重启分区,业务恢复正常
Part 2
分析过程
2.1故障分析思路
集群中一个节点宕掉,其他节点无法对外提供服务。
通常情况下,是因为当中的集群软件没有完成对整个集群状态、数据的重组,
因此数据未达到一致,所以集群其他节点无法对外提供服务。
这个环境中部署在IBM小机上,其中用到的集群软件有:
ORACLE RAC/ORACLE CRS/IBM HACMP
因此,需要分别查看这三个集群是否完成了重组、重新配置
2.2 确认ORACLE RAC是否完成重组
查看一节点数据库alert日志,可以看到,RAC集群在16点1分32秒就完成了重组。
可排除该问题。
2.3 确认ORACLE CRS是否完成重组
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的接管情况
![1452835939159217.png blob.png](http://www.e7wei.cn/Uploads/user/20160115/1452835939159217.png)
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数据以获得操作系统性能
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 如何找到突破口
小y把方向定到了操作系统,但是操作系统专家检查并否认操作系统有异常。
对于存活节点nmon为什么停止写入的问题,双方持不同意见。
至此,问题分析陷入僵局,小y开始思考,该如何继续往下分析呢?怎么能证明操作系统的异常呢?
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无法连接数据库又有什么关系呢?
当小y看到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来修复该问题。
Part 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冗余性丢失,建议定期做高可用测试,可以选择在变更窗口选择逐个重启实例、服务器的方式来进行验证。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30787320/viewspace-1979036/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/30787320/viewspace-1979036/