根本原因是memberkillescalation特性被触发：当节点1因存储链路抖动导致磁盘心跳丢失、io阻塞但ocssd进程未完全宕机时，节点2发起member kill请求，30秒超时后升级为node kill，强制重启节点1。
memberkillescalation 是根本原因，不是存储链路抖动本身导致宕机，而是 rac 在检测到节点失联后，因无法完成“驱逐”动作而升级为强制 node kill。
MemberKillEscalation 触发的真实条件
- 它只在 Oracle 11gR2 及以后版本启用，默认开启，不可关闭（除非打补丁禁用）
- 前提是集群已判定某节点“疑似失效”，但该节点的
OCSSD进程仍存活（未完全 hang 死），只是无法响应心跳或写入表决盘（Voting Disk） - 节点2发起
member kill请求后，等待30 秒（硬编码值，不可调）；超时即触发 escalation，写入 VF kill block 并强制重启目标节点 - 若目标节点此时已失去 IO 能力（如多路径中断、HBA 卡挂起），就无法读取 VF kill block，也无法主动退出，最终由集群仲裁裁定其“死亡”
常见错误现象：
-
ocssd.log中出现clssscMonitorThreads clssnmvDiskPingThread not scheduled for ... msecs - ASM 日志报
WARNING: Waited 15 secs for write IO to PST disk -
crsctl check cluster -all显示部分节点状态为UNKNOWN或长时间ONLINE但无响应
存储链路抖动为何容易踩中这个机制
- 抖动 ≠ 完全断开：链路短暂中断（
- 多路径切换失败时，
multipathd报mark as failed，但底层设备节点（如/dev/mapper/mpathX）可能卡在阻塞态，导致 ASM 和 OCSSD 线程 hang 住 -
OCSSD依赖磁盘心跳维持成员资格，一旦连续丢失 3 次（默认），就触发驱逐流程；而抖动刚好卡在“够触发但不够彻底宕机”的窗口期
关键参数影响：
-
misscount（默认 30 秒）决定心跳丢失多久后启动驱逐，但它控制的是“开始驱逐”，不是“完成驱逐” -
disktimeout（默认 200 秒）影响 Voting Disk 不可用时的容忍时间，但MemberKillEscalation的 30 秒超时独立于此
为什么冷重启反而比自动恢复更常见
-
MemberKillEscalation后，被 kill 的节点若未能干净 shutdown（比如内核已 hang），reboot就会失败，只能手动断电/冷启 - 冷启前必须确认：
crsctl stop crs -f是否能执行成功；若OCSSD卡死，kill -9可能无效，因为信号无法送达 - 集群重配完成后，原故障节点即使恢复网络和存储，也需人工运行
crsctl start crs才能重新加入，否则长期处于OFFLINE
容易被忽略的细节：
-
Voting Disk必须放在稳定、低延迟路径上；放在同一套抖动 SAN LUN 上，等于把“裁判”和“赛场”放一起 -
ASM实例对 PST（Partner Status Table）IO 超时是 15 秒，而 OCSSD 心跳间隔默认 1 秒，但实际检测窗口远大于此，抖动持续 > 5 秒就极可能连锁触发 - Linux 内核参数
vm.swappiness=1和kernel.panic_on_oops=1在 RAC 场景下反而会加剧非计划重启，应慎用
