根本原因是私网链路缺乏真实物理冗余，导致CSSD在默认misscount=30秒窗口内反复误判节点死亡；需通过双网卡跨设备、禁用proxy_arp、多路径voting disk及严格时钟同步等措施实现真正冗余。
根本原因不是“网络偶尔丢包”，而是私网链路缺乏真实冗余，导致 CSSD 在 misscount 窗口内反复误判节点死亡。
为什么misscount=30会频繁触发驱逐？
Oracle 11g RAC 默认 misscount 是 30 秒——即连续 30 秒没收到对端网络心跳，CSSD 就启动仲裁。但现实中的网络抖动（如交换机 STP 收敛、ARP 延迟、光模块软故障）常在 10–25 秒内发生。单路径私网下，一次抖动就可能踩中阈值。
- 查证命令：
crsctl get css misscount，确认当前值；日志中搜CRS-1601或ORA-29702可定位驱逐起因 - 不要盲目调大
misscount：它不解决根本问题，反而延长故障发现时间，且可能掩盖底层网络隐患 - 真正有效的做法是让抖动无法中断心跳流——靠多路径，不是靠拉长容忍时间
双网卡≠真冗余：常见物理层陷阱
很多环境配了 bond0（mode=1），两块网卡也连了两台交换机，但驱逐仍频繁。问题出在“物理隔离”失效：
- 两台交换机共用同一 UPS 供电回路 → 断电时同时宕机
- 两台交换机上联到同一核心设备（即使不同端口）→ 核心故障 = 全私网中断
- 网线实际都插在同一台交换机（仅端口不同）→ 拔错线就等于单点
- 未禁用私网子网的
proxy_arp和icmp_redirect→ ARP 行为异常干扰心跳包路由
验证方法：tcpdump -i bond0 port 12345 -c 100 抓 CSSD 心跳包，确认始终只从一个接口发出；再拔掉 eth1，看是否秒切 eth2 且 ping -I bond0 -c 5 <peer_private_ip></peer_private_ip> 无丢包。
voting disk路径配置不当会放大脑裂风险
即便私网稳，如果 voting disk 本身单路径或与 OCR 共盘，disk heartbeat 就不可靠。CSSD 依赖它做最终仲裁，一旦磁盘心跳也延迟或丢失，就会直接触发 node kill 而非等待投票。
- 必须用多路径软件（如 DM-Multipath）暴露统一设备名（如
/dev/mapper/vote01），不能直接绑裸盘（如/dev/sdb） - OCR 和 voting disk 必须分属不同 LUN —— 官方明确禁止共盘，否则任一路径故障会导致两者同时不可达
- voting disk 数量应为 ≥3 个奇数，分散在不同存储控制器上；
crsctl query css votedisk查状态，确保每个盘都显示ONLINE
容易被忽略的时钟与 ticket 资源耗尽
时间不同步和内部消息队列枯竭，也会表现为“无明显网络问题却频繁驱逐”：
- CTSS 日志出现
offset > 1000ms：NTP 源漂移过大，CSSD 会主动终止节点以保一致性；需用ntpq -p和hwclock --show同步 BIOS 与系统时钟 - lms0 进程 trc 中出现
Pending send queue或ticket remaining = 0：说明 IPC 消息通道拥塞，默认_lm_tickets（1000）不够用，尤其在高并发 DML 场景；可临时加至 2000，但需排查是否存在 Bug（如 11.2.0.4 的 Bug 18124792）
真正的稳定不是靠调参堆叠，而是让每条心跳通路都有独立物理载体、每个仲裁资源都可被单独验证——脑裂从来不是概率事件，而是冗余设计缺位的必然结果。
