mysql集群启动失败_系统Oracle数据库集群节点启动失败故障处理案例

前言

在oracle运维中经常会遇到各种故障，很多初中级dba遇到故障时都不知道该怎么处理，尤其在面对oracle RAC故障时更加束手无策，其实集群故障不可怕，只要掌握处理问题的思路，问题就迎刃而解。本次分享一个oracle数据库集群故障处理的真实案例，希望通过此故障案例分享，能给相关从业人员在处理类似故障时带来一些启发。

故障情况描述

开发人员邮件报障：云平台一套RAC数据库节点一启动失败，报错信息为：

ORA-01078: failure in processing system parameters

ORA-01565: error in identifying file '+DATA/wxdorcl/spfilewxdorcl.ora'

ORA-17503: ksfdopn:2 Failed to open file +DATA/wxdorcl/spfilewxdorcl.ora

ORA-29701: unable to connect to Cluster Synchronization Service

故障处理情况

1)描述云平台一套RAC数据库集群节点一启动失败，节点二运行正常，暂不影响业务正常运行，需对故障节点进行修复。

2)通过远程登录到现场RAC服务器节点二，检查集群状态及集群资源信息，发现节点二数据库实例在启动状态，CRSD进程连接异常，集群CRSD服务丢失，检查无节点一集群信息。

3)在节点二对数据及OCR进行备份，强制重启CRS服务后恢复正常。

4)登录节点一服务器查看集群信息及状态，OHASD进程异常。

5)检查节点一系统日志，在7月11日的09:45分系统登录还在正常状态，到09:46:04用户切换出现异常，09:48分系统开始重启。

6)继续检查数据库日志并未看到有驱逐节点的信息，而节点一在7月11日9点48分左右重启，怀疑是在未正常停库情况下重启了系统，节点一报网络错误，OCR连接异常，RPC失败等信息。

7)检查ASM磁盘的权限信息赋权正常。

8)节点一进行重置GI ohas的操作，Ohasd进程启动失败。

发现在等待init.ohasd启动超时，不能获取GPnP profile，怀疑目录权限不正确或者缺少文件。

9)对比两个节点间CRS_HOME/bin目录权限，发现节点一bin目录权限不正确，在节点二中拷贝bin目录覆盖节点一后手动启动OHASD成功，再执行root.sh脚本，报错信息如下：

10)启动asm实例报错，截取了报错的日志信息如下图，可以看到第一行开始InstAgent，然后进行clsdmc_respget检查(两个节点上私网网卡绑定的HAIP进行通信检查)多次通信未成功，然后报错ORA-03113: end-of-file on communication channel，直接把和ASM信息的数据库断开。

经Ping测试两节点HAIP不通。

11)gR2起Grid infrastructure引入资源ora.cluster_interconnect.haip，不需要第三方技术便可实现redundant interconnect，最多支持4个private network，提供load balance & failover功能；Gird会自动选取169.254.*.*作为HAIP address，该功能默认启动。

将HAIP不通情况反映给网络侧协助处理，放通两节点间169.254网段的双向互访。

经网络管理员放通两节点间169.254.x.x地址互通后，重新执行root.sh脚本正常，节点一已加入集群。

结论及建议

1. 两节点间HAIP地址不能正常通讯问题，在数据库安装时已出现过，当时处理方式是放通固定的169.254.X.X IP互访，数据库重启后HAIP重新获取但不能通讯，此时建议放通两节点间169.254网段的双向互访；

2. CRS_HOME目录权限的变更导致OHASD进程启动异常，建议在系统或数据库做安全整改项目时，记录变更操作并做验证，有些配置变更并非实时生效，如数据库静态参数的修改需等到重启以后才会生效。

3. 在对数据库日志进行分析时，如果的日志信息中存在OCR自动备份报错，一般是由于磁盘空间不足引起，建议在数据库周期性检查工作中应多关注磁盘的使用情况，以便及时扩容，预防此类故障。

END