表决磁盘是集群仲裁核心，通过多数派投票决定节点存留；2节点集群须配≥3个物理副本防平局，且需硬件fencing保障IO隔离，I/O路径延迟超500ms即可致Quorum丢失。
脑裂发生时，表决磁盘（Voting Disk）到底起什么作用？
表决磁盘不是“存储数据的地方”，而是集群判断“谁该活下来”的投票箱。当私网心跳中断（比如 misscount 超时），节点间无法确认彼此是否还活着，这时每个节点就去读 voting disk 上的最新投票记录——它不保存状态，只保存“最近一次成功写入的子集群身份”。只要一个节点能正常访问多数 voting disk（即满足 quorum），它就认为自己属于“合法子集群”；否则，就被判定为孤立节点，触发驱逐。
- 2节点集群必须配奇数个 Voting Disk（至少3个），否则无法打破平局——否则一断私网，两边都觉得自己是“多数”，谁都杀不死谁
- Voting Disk 必须放在 ASM 磁盘组中，且该磁盘组不能启用 ASM 的
disk_repair_time延迟剔除逻辑，否则磁盘临时不可用会被误判为永久故障 - 不要把 Voting Disk 和 OCR 放在同一个 LUN 或同一块物理盘上——单点故障会同时摧毁仲裁+配置，直接导致整个集群不可恢复
为什么加了 Quorum Device 还是脑裂了？
Quorum Device（比如 NFS 共享文件或第三方仲裁服务）本质是“第 N+1 票”，但它只解决“票数平局”问题，不解决“票被抢走”或“票写失败”的问题。常见失效场景是：NFS 服务器响应延迟 > disktimeout（默认 200s），导致所有节点都写不进新投票，于是各自按旧记录判断，回到无仲裁状态。
- 检查
crsctl get css disktimeout和实际 Quorum Device 的 RTT（尤其跨机房 NFS），RTT 必须稳定 disktimeout - Quorum Device 文件权限必须为
grid:oinstall且 644，否则 CSS 进程无法写入（日志里会出现CLSGPNP_ERR类错误但不报具体原因） - Oracle 12.2+ 支持基于权重的驱逐，但 Quorum Device 本身不参与权重计算——权重只影响实例层重连决策，不影响 Voting Disk 投票结果
两节点集群最容易踩的三个配置坑
两节点是最容易出脑裂的拓扑，不是因为简单，而是因为容错边界太窄。很多“看似正常”的配置，在私网抖动瞬间就会触发非预期驱逐。
- 没配冗余私网：只有一条 10G 私网链路？一旦该链路丢包率 > 1%，
misscount=30很快超时。必须绑定双链路（如 Linux bonding mode=active-backup）或配置双网卡多路径（ifconfig bond0:1） - Voting Disk 只有 1 份：哪怕用了 ASM 冗余（NORMAL），ASM 冗余 ≠ 集群仲裁冗余。必须通过
crsctl replace votedisk显式添加至少 3 份物理副本（分布在不同存储路径） - OCR 备份未验证：用
ocrconfig -showbackup查到备份存在，不等于能恢复。定期用ocrconfig -restore在测试环境试跑一次，否则真出事时发现备份文件权限错、时间戳异常、或跨版本不兼容
驱逐后节点没重启？说明 IO Fencing 失效了
驱逐（eviction）只是集群层标记该节点“出局”，真正防止数据损坏的是 IO Fencing——让被驱逐节点彻底失去对共享存储的写能力。如果驱逐后节点还在往 +DATA 磁盘组写数据，那不是脑裂没处理好，是 fencing 根本没生效。
- 检查
crsctl stat res -t | grep fence，确认ora.cluster_interconnect.haip和ora.asm资源状态为 ONLINE；若为 INTERMEDIATE，说明 HAIP 初始化失败，fencing 通道不通 - Linux 下确认
/etc/sysconfig/oracleasm中ORACLEASM_SCANORDER包含所有 voting disk 对应的设备名（如sdb sdc sdd），顺序错误会导致 CSS 读不到全部盘 - 不要依赖 Oracle 自带的软件 fencing（如 reboot）——它慢（平均 90s 才完成），且可能被内核 hang 住；硬件 fencing（SCSI-3 PR）才是生产首选，但需存储阵列支持 Persistent Reservation
