Keepalived脑裂后数据一致性受损，补救需人工介入：立即冻结双节点写入，比对binlog/WAL定位冲突，按业务语义择一回滚或合并，重建可信主库并加固防护。

Keepalived双机热备发生脑裂后，数据一致性已受损，补救不是靠Keepalived本身完成的——它不管理应用层数据，只管VIP抢占。真正关键的是：**立即阻断写入、人工比对、按业务语义择一回滚或合并，并重建可信主库**。整个过程必须停止自动切换，全程人工介入。

第一步：立刻冻结双节点写操作

脑裂期间若后端是MySQL、PostgreSQL等有状态服务，两端可能已各自接受写请求。必须马上切断所有外部写入流量：

• 在负载均衡器（如HAProxy）上临时禁用写接口路由，或直接下线写服务端口
• 登录两台数据库，执行SET GLOBAL read_only = ON（MySQL）或pg_ctl stop -m fast（PG只读模式需配合配置），防止继续写入
• 检查应用日志，确认最后写入时间点（LWT），标记脑裂窗口期（例如：2026-05-27 14:22:03 ~ 14:28:17）

第二步：识别并定位冲突数据范围

不能全量覆盖或盲目选主，要基于业务逻辑判断哪些数据可恢复、哪些必须舍弃：

• 查binlog或WAL：MySQL用mysqlbinlog --start-datetime="..." --stop-datetime="..."提取脑裂时段的变更；PG用pg_waldump解析wal段
• 重点扫描带唯一约束的表（如orders、users）、递增ID主键、时间戳字段（created_at/update_at），这些最易冲突
• 若使用GTID或LSN，对比两端gtid_executed或pg_last_wal_replay_lsn，找出分叉点

第三步：按业务规则决策恢复路径

没有通用方案，取决于你的数据模型和容错要求：

• 主从强同步场景（如MySQL半同步+rpl_semi_sync_master_wait_point=AFTER_SYNC）：以原主库为准，将备库通过CHANGE MASTER TO ... GTID_SUBSET重放至一致，跳过脑裂期间备库自写部分
• 无全局事务ID的异步复制：导出两端脑裂时段的INSERT/UPDATE/DELETE语句，人工比对业务含义（例如：“用户支付成功”不能重复，“库存扣减”不能漏），保留时间戳更新更晚、或业务单据号更大的记录
• 最终一致性服务（如订单+库存分离）：启用补偿任务，调用幂等接口校验并修复（如遍历订单表，反查库存流水，补发扣减或释放）

第四步：修复后验证与防护加固

数据拉齐只是起点，不加固就会再裂：

• 验证：用脚本比对关键表行数、checksum（如pt-table-checksum）、抽样字段值，确认两端完全一致
• 重启Keepalived前，先停掉所有健康检测脚本，手动指定主节点启动（systemctl start keepalived && ip addr add VIP/32 dev eth0），备节点仅启动keepalived但禁止升主（配置nopreempt + 优先级设为1）
• 上线后，开启vrrp_garp_lower_prio_delay和网关ARP刷新机制，避免客户端缓存旧MAC；同时部署仲裁脚本（ping网关+第三方HTTP探针），下次心跳中断时主动降权而非抢主