DBA小y
作者DBA小y2017-11-03 11:41
系统工程师, 中亦科技

风险提示:修改参数一定要确保重启后仍然生效!!

字数 2154阅读 2408评论 0赞 2

作者:高斌


问题来了:

用户一套11.2.0.3 的双节点RAC系统安装在AIX7.1 上。两个节点启动之后,一定会有一个节点的ora.crsd 资源处于INTERMEDIATE状态,换句话说:就是有一个节点的crsd 启动不起来,那后面的VIP, listener 等资源自然也就不能被启动了。但是让客户觉得奇怪的是问题并不固定在某一个节点上,有时是节点1,有时会变成节点2。

事实上,上述的描述信息我们可以简单的通过一个命令crsctl stat res -t -init来说明:
微信图片_20171103113552.jpg

微信图片_20171103113552.jpg

从上面信息可以看到,gpnpd/gipcd/cssd等进程都已正常,启动到crsd进程时出现了异常,最终我们无法使用crsctl stat res -t命令来查看crs服务的情况;

如果遇到这样的情况,你会如何进一步跟进核查呢?不妨停下来想一想自己以往的解决方案或者遇到这样的问题你会如何解决........

分析过程

事实上上面的问题还是很清晰的,那么就直奔主题,先看看crsd.log 里面是否出现了错误,导致了crsd 资源无法被启动;
微信图片_20171103113631.jpg

微信图片_20171103113631.jpg

上面的信息说明,crsd进程的确尝试了和gipcd 进程进行通信, 以便获取链接远程节点xxxx-2 的相关信息,但是很遗憾并没有找到。
那为什么会找不到呢?难道是本地或者对端的gipc进程出了问题了吗?从我们前面看到的gipcd服务进程已经启动,首先这里我们就可以排除掉,那会不会还有别的情况呢?

这里要解释一下原理来帮助读者理解为什么crsd要和gipcd进行通信。

原理解释:从11gR2版本的集群开始,gipc作为一个集群的新的资源(或者叫守护进程)被引入,它的功能是管理本地节点作为心跳网络(也称为集群的私网)的网卡,而且,本地节点的gipc进程还需要通过私网网卡和远程节点的私网网卡建立链接,而这样做的主要目的就是因为Oracle的集群管理软件从11gR2 版本开始支持多块私有网卡。而crsd作为集群的应用程序资源管理组件,它需要和gipc进行通信来获得到远程节点的一个链接,以便和远程节点的crsd 进行通信,完成自己的初始化过程。关于更多gipc的信息,可以参考《Oracle RAC 核心技术详解》中对gipc的介绍。

悬念

既然知道了原理,那么接下来要做的就是看看在gipc 层面出现了什么问题。以下是节点1的gipcd.log信息:
微信图片_20171103113853.jpg

微信图片_20171103113853.jpg

微信图片_20171103113902.jpg
微信图片_20171103113902.jpg

看起来网卡en2 是作为私网网卡被使用的,而且它的状态也是正常的,但是这段信息gipcdMonitorCssCheck:updating timeout node xxxx-2引起了我的注意,gipc尝试向远程节点发送了一些信息,却发生了超时。
gipc通信超时?难道是节点间的私网通信不通导致的?
答案是否定的!如果是节点间私网私信不通,那么一定这里我们就不会看到cssd进程正常了;对于CRS来说,cssd进程管理了RAC间的网络心跳,如果私网不通,那么意味着cssd进程在启动时根本无法构建集群,同时HAIP也将无法启动,crsctl stat res -t -init命令的输出也会截然不同。

知识点:cssd加入集群是只需要boot ip能通信,一般就没有问题,而RAC上的ASM实例和DB实例需要HAIP(169.254系列ip)正常时才能正常启动(在HAIP未被禁用的情况下)。

思考

这个时候,就需要冷静一下,来思考是否有别的可能了。既然问题是信息发送不过去,而别的组件通信是正常的,而不同的组件之间通信时会使用不同的端口,消息的长度也可能不同,那么还有两种可能:

  1. UDP或者TCP的端口范围有问题
  2. UDP或者TCP的发送或者接收缓冲区大小有问题。

当然还可能是其他和网络相关的参数设置导致的,不过这种可能性要小很多。

分析到这里之后,在MOS上找了一下AIX环境中针对网络相关参数的推荐值,以下是一部分参数和它们的推荐值:
微信图片_20171103114022.jpg

微信图片_20171103114022.jpg

用户在检查了相关的参数之后,发现原来是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 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广