不知不觉,技术人生·我和数据中心的故事来到了第二期,有朋友开始关心小y是谁,这不重要,我们更关心的是技术层面的分享以及给客户带来的实际的风险提示。后续我们还会继续分享中包括操作系统的小亦,中间件的小W的故事....小y这个名字,其实没有什么特殊的含义,就暂且用他来代表我们这些为数据中心奉献自己无悔青春的运维人吧!
小y今天要和大家分享的是下面这么一个严肃的话题:
换句话说:
当Oracle RAC集群中的一个节点所在的分区/服务器宕掉的时候,
你是否可以和领导拍着胸脯说,
“没的事,这是Oracle RAC,还有一个节点呢!只要该节点可以抗住负载,完全可以正常对外提供服务!”
如果你再把上面那段话读一遍,是否有开始犹豫的感觉了呢?
小y再换个方法来问一下这个话题:
虽然系统上线前做过RAC高可用测试,但是当集群中的一个节点长时间运行,包括CPU、内存,进程数在内的负载在不断变化,并且又经历了一些列变更后,期间又没有再做过高可用测试,这样的情况下,如果RAC一个节点所在的分区/服务器宕掉的时候,你是否依然可以拍着胸脯坚定的说,“我的Oracle RAC其他的节点一定可以正常对外提供服务!”?
同样的问题，当多了一些话语的铺垫后，再次听到这个问题的你，答案是否又更加犹豫了呢？
小y今天就为大家奉献一个“RAC高可用丢失”的真实案例及其完整、真实的分析过程。
了解到导致Oracle RAC高可用失效的一些具体因素。
小y估计不少朋友的系统中依然还存在类似的问题，
建议参考本案例进行细致检查,排除隐患。
这个案例会有不小的难度，客户为了分析该问题发生的根因，投入了大量的人力和时间，一度没有结果。小y接手该case后，在缺少信息的情况下，问题的分析也一度陷入僵局。不过小y最终还是通过反复梳理所有线索，从一个和数据库毫不相关的小细节中找到了突破口，成功定位到了问题原因。大家可以借鉴一下这样的方法。
现象：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重启分区，业务恢复正常
2.1故障分析思路
集群中一个节点宕掉，其他节点无法对外提供服务。
通常情况下，是因为当中的集群软件没有完成对整个集群状态、数据的重组，
因此数据未达到一致，所以集群其他节点无法对外提供服务。
这个环境中部署在IBM小机上，其中用到的集群软件有：
ORACLE RAC/ORACLE CRS/IBM HACMP
因此，需要分别查看这三个集群是否完成了重组、重新配置
2.2 确认ORACLE RAC是否完成重组
查看一节点数据库alert日志,可以看到，RAC集群在16点1分32秒就完成了重组。
可排除该问题。
