DRBD双主（Split-Brain）可通过cat /proc/drbd或drbdadm status判断：任一节点cs为StandAlone/WFConnection且ro含Primary/Unknown，或两节点均为Primary/Primary，结合dmesg中“Split-Brain detected”日志即可确诊。
DRBD 出现双主（Split-Brain）时，不能直接强制恢复；必须先确认哪边数据更新、哪边已过期，否则会丢数据。
怎么一眼判断是不是 Split-Brain
执行 cat /proc/drbd 或 drbdadm status，重点看 cs（connection state）和 ro（role）字段：
- 如果任一节点显示
cs:StandAlone或cs:WFConnection，且ro:Primary/Unknown或ro:Primary/Secondary中的“对方角色”是Unknown，基本就是脑裂 - 两个节点同时显示
ro:Primary/Primary是极危险信号（8.4+ 版本默认禁止，但旧配置或手动提权可能触发） - 日志里搜
dmesg | grep "Split-Brain"，出现Split-Brain detected, dropping connection!就是确诊
网络中断后如何确认哪边数据新
不能只看谁是“原 Primary”，要查实际写入时间。最可靠方式是比对底层文件系统最后修改时间或应用层日志：
- 在两台机器上分别运行：
stat -c "%y %n" /mnt/drbd-mount-point/any-recent-file（比如数据库的 binlog、MFS 的 chunk 文件） - 若挂载点不可读（
ds:Inconsistent或DUnknown），改查 DRBD 元数据时间戳：drbdadm dump data | grep -E "(disk|meta)"，再对比/var/lib/drbd/drbd-{minor}.meta的mtime - 注意：如果用了
on-io-error detach策略，某节点可能已变成diskless，此时它一定不是数据源 - 千万别依赖
drbdadm get-gi输出的 generation ID —— 网络断开期间双方都可能自增，无法反映真实写入顺序
修复时必须分清主次，命令不能颠倒
假设确认 node1 数据更新（应保留），node2 数据陈旧（需丢弃）：
- 在 node2（旧数据端）执行三步（顺序不能错）：
drbdadm secondary data→drbdadm disconnect data→drbdadm -- --discard-my-data connect data - 在 node1（新数据端）只执行：
drbdadm connect data（不是primary，它本来就是 Primary） - 执行完立刻检查：
cat /proc/drbd中 node1 应为cs:Connected ro:Primary/Secondary，node2 应为cs:SyncTarget ro:Secondary/Primary并开始同步 - 常见错误：在 node2 上漏掉
-- --discard-my-data，只用connect，结果 DRBD 拒绝连接并报Refusing to connect: missing data
为什么 wfc-timeout 和 after-sb-0pri 不能救急
这些是预防配置，不是修复手段。脑裂发生后它们已失效：
-
wfc-timeout 0会让节点无限等待重连，但 Split-Brain 触发后连接已被主动断开，等待无意义 -
after-sb-0pri discard-zero-changes只在“双方都是 Secondary 时重新提主”场景生效，而 Split-Brain 下至少有一方是 Primary - 真正起作用的是人工决策 +
--discard-my-data或--recover（后者极少用，要求双方都有完整变更日志） - 修复完成后务必检查
drbdadm verify data是否有块校验失败 —— 网络中断期间 IO 可能已损坏部分扇区
最易被忽略的一点：修复后不要立刻启动上层服务（如 MySQL、MFS）。先等 ds:UpToDate/UpToDate 出现，再 mount -o ro 挂载验证文件可读，最后才切回读写模式。同步未完成就挂载，轻则 IO hang，重则触发二次脑裂。
