RAC节点1重启后，节点1的资源为何没有failover到节点2？

来源：IPIPP.com作者：陈平安头衔：全栈工程师

导读：本期聚焦于小伙伴创作的《RAC节点1重启后，节点1的资源为何没有failover到节点2？》，敬请观看详情，探索知识的价值。以下视频、文章将为您系统阐述其核心内容与价值。如果您觉得《RAC节点1重启后，节点1的资源为何没有failover到节点2？》有用，将其分享出去将是对创作者最好的鼓励。

在Oracle RAC集群的运维场景中，节点1重启后资源未正常failover到节点2是常见的高可用相关问题，下面我们先通过一张示例图了解RAC集群的基本结构。

常见原因排查

RAC中每个资源都有对应的故障转移属性，如果配置不当会导致资源无法自动切换。可以通过CRSCTL命令查看资源的故障转移配置：

# 查看指定资源的属性，替换resource_name为实际资源名
crsctl stat res resource_name -p | grep "FAILOVER"

如果输出中FAILOVER的值为0，说明该资源未开启自动故障转移，需要手动修改配置：

# 开启资源的自动故障转移
crsctl modify res resource_name -attr "FAILOVER=1"

RAC集群依赖网络心跳和磁盘心跳检测节点状态，如果心跳链路在节点1重启期间出现异常，集群可能无法正确判断节点1的状态，导致不会触发资源转移。可以通过以下命令检查心跳状态：

# 查看集群心跳状态
crsctl check cluster -all
# 查看网络心跳详情
oifcfg getif

如果心跳网络存在丢包、中断的情况，需要先修复网络问题，再重启集群服务让配置生效。

部分资源存在依赖关系，比如数据库实例依赖ASM实例，如果ASM实例的故障转移配置未同步，或者依赖的资源未先完成切换，会导致上层资源无法转移。可以查看资源的依赖关系：

# 查看资源的依赖关系，替换resource_name为实际资源名
crsctl stat res resource_name -p | grep "DEPENDENCIES"

如果存在未正确配置的依赖项，需要调整依赖顺序，确保底层资源先完成故障转移。

如果节点1重启是因为被集群主动驱逐，而驱逐的原因未被正确处理，集群可能会将节点1标记为不稳定状态，暂时不允许资源重新分配或者转移到其他节点。可以查看集群的告警日志定位驱逐原因：

# 查看集群告警日志路径，根据安装路径调整
tail -f $GRID_HOME/log/hostname/alerthostname.log

常见的驱逐原因包括节点负载过高、IO超时、内存不足等，解决对应的问题后，手动触发资源重新分配即可。

完成上述排查和修复后，可以通过以下方式验证资源是否能正常failover：

如果以上步骤都验证通过，说明资源failover的问题已经解决，集群高可用能力恢复正常。

免责声明：已尽一切努力确保本网站所含信息的准确性。网站部分内容来源于网络或由用户自行发表，内容观点不代表本站立场。本站是个人网站免费分享，内容仅供个人学习、研究或参考使用，如内容中引用了第三方作品，其版权归原作者所有。若内容触犯了您的权益，请联系我们进行处理。