节点驱逐的真正条件是任一关键心跳路径（网络、磁盘或本地）在超时窗口内持续不可达，而非仅因网络心跳丢包；cssd 综合判断后触发驱逐，且需多数派节点共识。
节点驱逐触发的真正条件是什么？
oracle rac 不是因为“心跳丢包”就立刻驱逐节点，而是依赖 cssd 进程对多种心跳源（如网络心跳、磁盘心跳、本地进程心跳）的综合判断。只要任意一种心跳路径在超时窗口内持续不可达，cssd 就会启动驱逐流程——不是等所有路径都断，而是“任一关键路径失效且超时”。
常见误判场景：cssd 日志里出现 missed heartbeat from node X 并不等于已驱逐；真正驱逐前会有 node eviction initiated 明确标记。此时节点尚未重启，但已停止参与集群资源协调。
- 网络心跳默认每秒 1 次，连续 3 次未响应（即 3 秒）触发告警，但是否驱逐取决于
misscount参数 - 磁盘心跳（通过 voting disk）更可靠，但延迟更高；若网络中断而磁盘心跳仍通，节点通常不会被驱逐
-
cssd自身卡死（如 CPU 占满、OOM）会导致本地心跳失效，即使网络和磁盘都正常，也会被其他节点驱逐
如何安全调整 misscount 和 disktimeout？
misscount 是决定网络心跳容忍丢包次数的核心参数，单位是秒，但实际含义是“允许连续多少秒收不到心跳”。默认值为 30 秒（RAC 11gR2+），意味着节点需连续 30 秒无任何有效心跳才会被驱逐。盲目调大可能掩盖真实故障，调小则易引发误驱逐。
disktimeout 控制磁盘心跳超时（默认 200 秒），它必须大于 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/<host>/cssd/ocssd.log中是否出现evicting node或反复rebooting node
为什么改了阈值还是被驱逐？检查这三类底层问题
调整 misscount 只是延长容忍窗口，并不能修复根本原因。大量案例显示，90% 的非预期驱逐源于以下三类未被识别的底层异常：
-
cssd进程因 I/O 延迟卡住：voting disk 所在 ASM 磁盘组 IO 负载高（iostat -x 1查%util > 95或await > 50ms），导致磁盘心跳超时，此时调大disktimeout可能延缓但无法避免驱逐 - 私网配置错误：RAC 私网未使用专用网卡或未禁用 NIC offload（如
ethtool -K eth1 gro off lro off），造成心跳包被延迟或合并，表现为偶发性missed heartbeat - 系统级资源争用：SELinux 强制模式干扰
cssd访问共享设备；或kernel.sem设置过低（应 ≥250 32000 100 128），导致 IPC 信号丢失
验证驱逐逻辑是否按预期工作
不要依赖模拟网络断开（如 iptables -A INPUT -s <other-node> -j DROP）来测试，因为该操作可能只阻断部分心跳路径，结果不可复现。真实验证需分步隔离：
- 先停止单个节点的
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/<host>/cssd/ocssd.log | tail -50，注意时间戳是否与配置阈值吻合
复杂点在于：驱逐决策由集群中多数派节点共同完成，单节点日志只反映“被驱逐”，不体现“谁发起驱逐”。真要定位源头，得比对所有节点的 ocssd.log 时间线，找出第一个发出 evicting node 的节点及其前序心跳失败记录。
