于gipc进程导致的节点无法启动
发布网友
发布时间：2023-05-28 03:15
共1个回答
热心网友
时间：2024-01-23 11:04
问题描述：dba发现节点2被重新启动，之后无法加入到集群。
分析过程：
这实际上是两个问题，首先节点2被重新启动，之后节点2无法加入集群。这需要从集群的告警日志开始分析。
1. 节点1的集群alert.log
[grid@infirac1 infirac1]$ cd $ORACLE_HOME/log/infirac1
[grid@infirac1 infirac1]$ less alertinfirac1.log
alert日志报错信息如下：
network communication with node 2 missing for 50% of timeout interval. removal of this node from cluster in 14.190 seconds
2. 节点2的集群alert.log
[grid@infirac2 infirac2]$ cd $ORACLE_HOME/log/infirac2
[grid@infirac2 infirac2]$ less alertinfirac2.log
报错信息如下：
network communication with node 1 missing for 50% of timeout interval. removal of this node from cluster in 14.180 seconds
this node was evicted by node 1 details at in /u01/11.2.0/grid/log/infirac2/cssd/ocssd.log
the css daemon is terminating e to a fatal error;
starting clean up of CRSD resources
从上面的日志输出可以看出两个节点之间出现了私网通信问题，之后节点2被驱逐出了集群。
3. 两个节点的操作系统日志（/var/log/messages）
节点1的操作系统日志：
NIC link is down
link status definitely down for interface,disabling it
NIC link is up
bond0 link status definitely up for interface
节点1的操作系统日志显示节点1的网卡bond0出现过问题，但是随后又恢复正常了，这无法解释为什么节点2无法重新加入集群，因此还需要从节点2的ocssd.log来确定节点2无法加入集群的原因。
4. 节点2的ocssd.log
关键报错信息如下：
aborting ,evicted by node ****** number 1 sync 76357678 stamp 416434348
可以确定节点2是被节点1驱逐出了集群
starting CSS daemon version 11.2.0.3 in mode with uniqueness value 1342448763
ocssd被重新启动
return netdata 1 interfaces
create local bootstrap broadcast interface for node ****
节点2能够发现私网，并且通过gipc已经开始联系集群的远程节点
node 1 has d disk HB, but no network HB
私网和节点2的通信没有成功，因为节点2并没有通过网络心跳发现节点1，只在VF中找到了节点1的磁盘心跳信息。
takeover aborted e to cluster member node found on disk
cssd aborting from thread
a fatal error occurred and the css daemon is terminating abnormally
节点2无法连接到节点1，所以节点2会尝试接管集群，但是节点1仍然能够访问VF，所以节点2无法接管集群，只能再次abort掉。同样的过程会不断的重复出现。
根据上面的发现可以推断，问题可能还是出现在私网通信上，而11gR2版本的集群私网通信是首先需要通过gipc建立连接的，下面需要分析gipc.log日志来确定私网通信问题
5. 节点2的gipcd.log
[grid@infirac2 gipcd]$ cd $ORACLE_HOME/log/infirac2/gipcd
[grid@infirac2 gipcd]$ less gipcd.log
inf bond0 - rank 99
successfully connected to CSS
以上日志输出显示节点2的gipc没有问题，能够找到私网网卡，而且能够和ocssd进行通信
6. 节点1的gipcd.log
interface went down -[ip *.*.*.*,subnet *.*.*.*]
基于之前节点1的操作系统日志，看起来gipc也发现了私网存在问题，并将对应的网卡标记成了down的状态
不久之后网卡又恢复了正常
create remote bootstrap broadcast interface for node ****
gipc尝试向集群发布自己的信息
gipcMonitorSaveInfMetrics: inf bond0 - rank 0, avgms 30000.0000
gipcMonitorSaveInfMetrics: inf bond0 - rank -1, avgms 30000.0000
上面的信息说明gipc检查了私网的状态之后，认为私网存在问题，因为私网的rank值为0或者-1
根据上面的信息确定问题出现在节点1的gipc进程在私网网卡恢复正常后没有正确的检查私网的健康性，并将私网的rank值标记成了0或者-1。由于gipcd进程是由ohasd的代理进程管理的，即使这个进程被终止，代理进程会重新启动一个新的gipcd守护进程。
解决方法：
将节点1的gipcd进程使用操作系统命令kill掉之后，新的gipcd进程便产生。重新启动节点2，节点2可以加入集群了，问题解决。
[grid@infirac1 infirac1]$ ps -ef | grep gipcd
[grid@infirac1 infirac1]$ kill -9 2099
举报/反馈
