Oracle RAC 节点驱逐的真正触发条件是什么？
在 Oracle RAC 集群环境中，许多管理员存在一个普遍误解，认为“网络心跳丢包”会直接引发节点驱逐。实际上，Oracle RAC 的驱逐机制远比这复杂和严谨。驱逐的核心决策者是 cssd（集群同步服务守护进程），它如同一个高度可靠的裁判，会综合分析来自网络心跳、磁盘心跳以及本地进程心跳的多路信号。
节点被驱逐的根本条件是：任何一条关键心跳路径在预设的超时窗口内持续处于不可达状态。请注意，是“任何一条”而非“所有路径”。这意味着，只要网络、磁盘或本地心跳中有一条关键路径彻底失效并超过容忍时间，cssd 就会启动驱逐流程，而不会等待所有路径都中断。
节点驱逐的真正触发条件是任一关键心跳路径（网络、磁盘或本地）在超时窗口内持续不可达，而不仅仅是网络心跳丢包；cssd 综合判断后触发驱逐，且驱逐决策需获得多数派节点的共识。
这里有一个至关重要的诊断细节：在 cssd 日志中看到 “missed heartbeat from node X” 的警告信息，并不代表节点已被驱逐。这只是一个预警信号。真正的驱逐行动开始前，日志中会出现明确的 “node eviction initiated” 标记。此时，该节点虽然尚未重启，但已经停止参与集群的资源协调，进入了“准驱逐”状态。
- 网络心跳：默认每秒1次。连续3次未响应（即3秒）会触发告警，但最终是否驱逐，取决于
misscount这个核心参数的设定。 - 磁盘心跳：通过表决磁盘（Voting Disk）进行，可靠性更高，但延迟也相对较高。如果网络中断而磁盘心跳依然通畅，节点通常不会被驱逐。
- 本地心跳：指
cssd进程自身的健康状态。如果它因 CPU 占满、内存溢出（OOM）等问题而卡死，导致本地心跳失效，那么即使网络和磁盘心跳都正常，该节点也会被其他健康的节点投票驱逐。
如何安全调整 misscount 和 disktimeout 参数？
理解了驱逐逻辑后，调整相关参数就有了明确方向。misscount 是决定网络心跳容忍度的核心参数，单位是秒。其实际含义是“允许连续多少秒收不到任何有效心跳”。自 Oracle RAC 11gR2 起，其默认值通常为30秒。这意味着，一个节点需要连续30秒失去所有心跳联系，才会被判定为失效。盲目调大此值可能掩盖真实的硬件或系统故障，而调小则容易引发误驱逐，导致不必要的服务中断。
另一个关键参数是 disktimeout，它控制磁盘心跳的超时时间，默认值为200秒。这里有一条必须严格遵守的黄金法则：disktimeout 的值必须大于 misscount。否则，磁盘心跳可能永远来不及响应就被判定为超时，从而极大增加误驱逐的概率。
- 调优第一步——确认当前配置：执行
crsctl get css misscount和crsctl get css disktimeout命令，获取当前集群的配置值。 - 何时需要调整：如果环境存在频繁的网络抖动（例如在虚拟化环境或跨机架链路中），可以考虑将
misscount适度提高到45至60秒。但切记，必须同步将disktimeout设置为至少misscount + 30秒。 - 如何使修改生效：修改后，需要重启
cssd服务（使用crsctl stop crs && crsctl start crs）。并且，所有节点上的设置必须保持完全一致，否则集群可能无法正常启动。 - 修改后的观察期：切勿在生产系统业务高峰期进行修改。调整后，应至少观察48小时，重点检查
$GRID_HOME/log/日志中是否出现 “evicting node” 或反复的 “rebooting node” 记录。/cssd/ocssd.log
为什么调整了阈值节点仍被驱逐？排查这三类底层问题
必须清醒地认识到：调整 misscount 仅仅是延长了故障容忍的窗口时间，并不能修复导致心跳中断的根本原因。大量的运维案例表明，超过90%的非预期驱逐事件，根源在于以下三类未被及时发现的底层异常：
cssd进程因 I/O 延迟卡住：表决磁盘（Voting Disk）所在的 ASM 磁盘组如果 I/O 负载过高，会导致磁盘心跳响应超时。通过iostat -x 1命令查看，如果%util持续高于95%或await时间超过50毫秒，就需要警惕。此时单纯调大disktimeout可能只是延缓问题，而无法避免最终的驱逐。- 私网配置不当：RAC 私网未使用专用物理网卡，或者未禁用网卡的高级卸载功能（如通过
ethtool -K eth1 gro off lro off关闭 GRO/LRO）。这可能导致心跳包被延迟或合并处理，表现为偶发性的 “missed heartbeat”。 - 系统级资源争用与限制：SELinux 运行在强制模式可能会干扰
cssd对共享设备的访问；另外，操作系统内核信号量参数（kernel.sem）设置过低（建议值至少为250 32000 100 128）可能导致进程间通信（IPC）信号丢失，从而影响心跳。
如何验证驱逐逻辑是否按预期工作？
如何验证你的参数调整和系统配置是有效的？一个常见的误区是直接模拟网络断开（例如使用 iptables 规则阻断节点间流量）。这种方法不够精确，因为它可能只阻断了部分心跳路径，结果难以复现且无法全面验证逻辑。
更可靠的验证需要分步骤、有控制地进行隔离测试：
- 测试网络心跳失效的响应：在单个节点上，停止
cssd服务（crsctl stop res ora.cssd -init）。然后观察其他节点的日志，是否在misscount秒后准确记录了 “evicting node” 信息。 - 测试磁盘心跳失效的响应：临时卸载表决磁盘（Voting Disk）所在的 ASM 磁盘（
umount /dev/asm-diskX）。确认驱逐动作是在disktimeout秒之后才被触发，而不是立即发生。 - 关键日志监控：始终紧盯核心日志指标：
grep -i “evict\|missed\|reboot” $GRID_HOME/log/。仔细核对日志中的时间戳，看其间隔是否与配置的阈值参数吻合。/cssd/ocssd.log | tail -50
这里还有一个复杂点：驱逐决策是集群中“多数派”节点通过共识机制共同做出的。因此，单个节点的日志通常只记录它“被驱逐”的结果，而不会显示是“谁发起了驱逐”。要定位问题的源头，需要横向比对所有节点的 ocssd.log 日志时间线，找出第一个发出 “evicting node” 记录的节点，并追溯该节点在做出决策前的心跳失败记录。这才是完整的故障诊断链条。
