为什么Oracle 12c RAC在Flex Cluster模式下节点会自动下线

确认是CSSD主动驱逐而非系统崩溃：先查ocssd.log中“node eviction initiated”或“reboot advisory”时间是否早于系统重启记录，再结合crsctl stat res -t全OFFLINE与ps检查cssd进程状态综合判断。

不是“自动下线”，而是被 cssd 主动驱逐（eviction）——节点没死，是集群认为它失联了，强制踢出。

怎么确认是 CSSD 驱逐而非系统崩溃

别只看系统重启时间，得比对日志和进程状态：

• 查 ocssd.log：搜索 node eviction initiated 或 reboot advisory，如果出现时间早于 dmesg 或 /var/log/messages 里的 reboot 记录，就是集群主动驱逐
• 运行 crsctl stat res -t：若所有资源全为 OFFLINE，但 crsctl check cluster -all 显示节点 “ONLINE”，说明节点已注册但未加入通信环，卡在中间态
• 执行 ps -ef | grep cssd：若 cssd 进程消失或僵死，而 ohasd 还在，大概率是心跳中断后 CSSD 主动终止自身

Flex Cluster 下驱逐的三大隐性根源

Flex 架构放大了底层不稳的影响，尤其 hub/leaf 分离后，问题更容易被掩盖：

• voting disk 所在 ASM 磁盘组 IO 延迟高：iostat -x 1 中 %util > 95 或 await > 50ms → 磁盘心跳超时，调大 disktimeout 无效
• 私网“假通”：NIC offload（如 ethtool -K eth1 gro on）导致 TCP 重传异常，ping 通但 traceroute -n <private_ip> 路径不稳定
• ora.cluster_interconnect.haip 没起来：ip a | grep 169.254 无输出 → HAIP 失效，hub node 间心跳断，leaf node 会因依赖 hub 而集体失联

Flex Cluster 特有风险点：leaf node 间接引发 hub 驱逐

leaf node 本身不参与 voting，但它通过 hub node 访问数据；一旦 leaf node 上应用异常占用大量私网带宽或触发内核资源争用（如 UDP socket flood），可能拖垮所在 hub node 的网络栈，导致该 hub node 被其他 hub node 驱逐：

• 检查 netstat -s | grep -i "receiving errors" 和 cat /proc/net/snmp | grep -i "Udp:"，确认是否有 UDP 接收溢出
• leaf node 上运行中间件时，若未限制其网络连接数或未关闭 Nagle 算法，可能加剧私网拥塞
• hub node 的 cssd 日志中若频繁出现 missed heartbeat from node X，但 X 是 leaf node，则说明问题不在 X 本身，而在它所连接的 hub 节点负载过高

Flex Cluster 的分层设计让故障定位更隐蔽：leaf node 不挂，不代表 hub node 安全；hub node 没报错，也不代表私网链路健康。真正要盯的，是 HAIP 是否在线、voting disk 的 IO 响应、以及 traceroute 到每个私网 IP 的路径稳定性——这些细节一漏，驱逐就成常态。