拯救无法启动的集群（初始化资源篇）

“来自高斌老师的集群课”

1.查看集群版本crsctl query crs activeversion

2.检查集群状态/u01/app/11.2.0/grid/bin/crsctl check crs

3.启动集群的脚本

• /etc/rc.d/init.d/ohasd

• 11gR2及之后

• h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1</dev/null 起集群

• htfa:35:respawn:/etc/init.d/init.tfa run >/dev/null 2>&1</dev/null启动tfa(oracle自带)

• cat etc/inittab

• 10gR2&11gR1

• h1:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1</dev/null

• h1:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1</dev/null

• h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1</dev/null

• cat etc/inittab

4.启动集群所需要的基本文件

• socket 文件

• 位置在/usr/tmp/.oracle

• 这些文件在集群活动的情况下不能删，如果真的删除了，把集群重启下会自动生成

• /etc/oracle下的文件

• ./crsctl disable crs

• 通过/etc/oracle/scls_scr/lnx11204b/root下的ohasdstr来控制集群的自动启动

• $ORACLE_HOME/dbs

• 集群最开始起的进程ohasd.bin --读取olr.loc文件

• 配置文件（olr，表决盘vf，ocr）

• 关闭集群自动启动功能

5.若集群没起来

• 若ohasd进程没起来

• 1看olr.loc文件

• 2看是不是enable

• 3看是不是tmp下文件没了

6.集群的初始化层

• 10gR2&11gR1集群分三层

• cssd：集群的核心层，构建集群

• crsd：集群的应用程序资源层

• evmd：集群的事件发布层

• 11gR2+集群多一层，为适应云架构

• ohasd：启动集群的唯一源头（读olr）

• mdnsd：构建初始化层的通信通道

• 给gpnpd使用

• gpnpd：完成初始化层的集群构建

• # su - grid

• $ gpnptool find 发现节点

• $ gpnptool get 可以看到gpnp的profile文件，通过ClusterUID判断谁跟“我”是一个集群，通过network id对应网卡对外发消息

• 目的是为了云环境更方便的发现节点，例如A节点在数据中心1，B节点在数据中心2，通过xml2不用配置的网络，就可以很容易发现对应节点

• gipcd：完成集群的私网初始化

• 如果要跟对方节点通信，必须来找gipcd，你告诉我

• ps -ef|egrep 'mdns|gipc|gpnp'

• 这三个进程在集群启动时很重要，集群起来后就没那么重要了，属于高可用，可以kill掉，会自行立刻再产生新的进程

6.案例：由于不恰当的udp参数设置导致集群无法启动，11gR2两节点集群+AIX7.1

• 问题现象：改了一些参数，重启集群，其中一个节点集群起不来，GI无法启动

• crsctl stat res -t -init 看集群初始化资源层

• crsctl stat res -t 看应用程序层

• 实际操作

• UDP或者TCP的端口范围有问题

• UDP或者TCP的发送或者接收缓冲区大小有问题

• crsctl stat res -t看到无法与集群通信，crs没有起来

• 看crsd.log日志发现gipchaLowerProcessNode:no valid interfaces found 看起来问题是crsd和gipc在通信时出了问题

• crsctl stat res -t -init 看初始化资源层，gipc目前状态为intermediate，尝试启动下crsctl start res ora.gipcd -init若起来ok，没起来就继续看gipcd日志

• gipcd日志文件，网卡评分为99，说明私网网卡正常，看到updating timeout node xxxx-2 看起来是gipc尝试向远程节点发送一些信息，但是发生了超时。难道真的是私网存在问题，但是这种想法马上就被否定了，如果真的是网络问题，很难解释为什么ocssd进程在2个节点都可以正常运行，这意味着集群是能够构建起来的，如果真的是网络上出现了问题，没有理由问题只出现在crsd层面

• 分析：冷静一下，来思考是否有别的可能，既然问题是信息发送不过去，而别的组件通信是正常的，而不同的组件之间通信会使用不同的端口，消息的长度也可能不同，那么还有2种可能

• 最后发现此节点的udp_sendspace 8192，其他的都是65536，节点1的udp_sendspace也是65536，所以问题就出在这。