作者:高斌
问题来了:
用户一套11.2.0.3 的双节点RAC系统安装在AIX7.1 上。两个节点启动之后,一定会有一个节点的ora.crsd 资源处于INTERMEDIATE状态,换句话说:就是有一个节点的crsd 启动不起来,那后面的VIP, listener 等资源自然也就不能被启动了。但是让客户觉得奇怪的是问题并不固定在某一个节点上,有时是节点1,有时会变成节点2。
事实上,上述的描述信息我们可以简单的通过一个命令crsctl stat res -t -init来说明:
如果遇到这样的情况,你会如何进一步跟进核查呢?不妨停下来想一想自己以往的解决方案或者遇到这样的问题你会如何解决........
事实上上面的问题还是很清晰的,那么就直奔主题,先看看crsd.log 里面是否出现了错误,导致了crsd 资源无法被启动;
这里要解释一下原理来帮助读者理解为什么crsd要和gipcd进行通信。
原理解释:从11gR2版本的集群开始,gipc作为一个集群的新的资源(或者叫守护进程)被引入,它的功能是管理本地节点作为心跳网络(也称为集群的私网)的网卡,而且,本地节点的gipc进程还需要通过私网网卡和远程节点的私网网卡建立链接,而这样做的主要目的就是因为Oracle的集群管理软件从11gR2 版本开始支持多块私有网卡。而crsd作为集群的应用程序资源管理组件,它需要和gipc进行通信来获得到远程节点的一个链接,以便和远程节点的crsd 进行通信,完成自己的初始化过程。关于更多gipc的信息,可以参考《Oracle RAC 核心技术详解》中对gipc的介绍。
既然知道了原理,那么接下来要做的就是看看在gipc 层面出现了什么问题。以下是节点1的gipcd.log信息:
知识点:cssd加入集群是只需要boot ip能通信,一般就没有问题,而RAC上的ASM实例和DB实例需要HAIP(169.254系列ip)正常时才能正常启动(在HAIP未被禁用的情况下)。
这个时候,就需要冷静一下,来思考是否有别的可能了。既然问题是信息发送不过去,而别的组件通信是正常的,而不同的组件之间通信时会使用不同的端口,消息的长度也可能不同,那么还有两种可能:
当然还可能是其他和网络相关的参数设置导致的,不过这种可能性要小很多。
分析到这里之后,在MOS上找了一下AIX环境中针对网络相关参数的推荐值,以下是一部分参数和它们的推荐值:
用户在检查了相关的参数之后,发现原来是udp_sendspace 参数出现了问题,被设置成了8192。看到了这里,基本上就真相大白了,原来是这个参数太低,导致了gipc 在发送一些信息给远程节点的gipc 时信息被截断了,造成了这个问题。
用户在把这个值修改成655360 , 并重新启动了两个节点的gipcd.bin 进程之后,问题就被解决了。这里要说明一下的是,所谓重启gipcd.bin 就是指使用操作系统的“kill -9 <process id of gipcd.bin >”命令来中止gipcd.bin 进程,集群在发现这进程被终止之后,会自动启动新的进程。这种方式对集群的运行并没有影响。
后续与用户的沟通中我们了解到,原来用户的确是想把参数udp_sendspace 从原来的8192改成65536,而且也确实改了,但是之前的修改在重启之后并没有生效,才导致了问题。
在此,小编正式提醒各位伙伴改参数的时候一定要特别注意,否则后续可能会有一系列的问题随之而来!!
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞2
添加新评论0 条评论