脑裂问题只能预防，不能修复——通过投票磁盘法定人数机制强制隔离故障节点；Oracle RAC依据节点对多数投票磁盘的访问能力（而非心跳顺序）决定驱逐对象，由CSS自动执行。
脑裂问题不能“修复”，只能“预防”——一旦发生，数据冲突已成事实，所谓“解决”其实是靠提前设计的表决机制，在网络断开的瞬间就强制让一部分节点停止服务，不给写入机会。
为什么投票磁盘（voting disk）能决定踢谁？
Oracle RAC 不靠“谁先心跳断”来判断故障，而是看谁能访问到多数投票磁盘。每个节点持续向所有投票磁盘写入“心跳块”（称为 disk heartbeat），同时读取其他节点留下的最新时间戳。当私网中断，集群分裂成两组时：
- 节点数多的一组，大概率能访问到 ≥(N/2)+1 个投票磁盘，满足 Quorum，继续运行
- 节点数少或磁盘路径受损的一组，读不到足够数量的、新鲜的心跳块，被判定为“失去法定人数”，立即触发
eviction - 注意：不是“投票选谁滚”，而是“谁达不到法定访问能力，谁就被踢”——踢出动作由 CSS（Cluster Synchronization Services）自动触发，无需人工干预
crsctl get css misscount 超时值设太小反而更危险
这个值（默认 30）不是“容忍断连多久”，而是“允许连续丢失多少次磁盘心跳”。它和实际网络抖动强相关：
- 设成
10：轻微丢包就可能触发误驱逐，尤其在高负载、I/O 延迟波动大的存储环境 - 设成
60：虽降低误判，但若真发生严重网络分区，错误节点会多活 30 秒，极大增加脏写风险 - 真实建议：保持默认
30，但必须配合稳定的多路径存储（如 multipath + ALUA），避免单条路径抖动被误判为磁盘不可达
偶数节点 RAC 必须加仲裁盘（Quorum Device）
2 节点 RAC 是最危险配置：网络一断，必然 1:1 分裂，两边都刚好能访问 1 个投票磁盘（假设共 2 个），谁都凑不够多数。此时仅靠磁盘心跳无法打破平局：
- 必须引入第三方仲裁设备（如 NFS 共享文件、ASM Flex Diskgroup 中的 quorum failgroup）作为“第 3 票”
- 该设备不存业务数据，只参与心跳计票；它和两个节点之间需有独立、低延迟的网络路径（不能走同一交换机）
- 切忌用管理网挂 NFS 仲裁盘——管理网一旦和私网共用物理链路，仲裁路径和心跳路径就耦合了，等于没加
真正难的不是配置投票磁盘，而是验证它在各种故障组合下是否真能按预期工作。比如模拟私网断+某条存储路径断+节点高负载，这时候 CSS 日志里 evicting node X due to loss of voting disk connectivity 是否准时出现，比任何文档都管用。
