双主热备必须配对设置auto-increment-offset和auto-increment-increment以避免自增主键冲突，否则会导致Slave_SQL_Running: No及ERROR 1062重复主键错误；server-id须全局唯一且非0或1；验证需双向检查SHOW SLAVE STATUS\G中三个关键字段并实测数据同步。
server-id 必须不同，auto-increment-offset 和 auto-increment-increment 必须配对设置，否则写入冲突会导致复制中断——这是双主热备最常踩的坑。
为什么不能直接照搬主从配置做双主
主从复制中从库只读，SQL线程按序重放日志，天然避免冲突；而双主（Master-Master）允许两端同时写，一旦两个节点对同一张表用 AUTO_INCREMENT 插入新行，就可能生成重复主键，触发 Slave_SQL_Running: No。错误日志里通常能看到类似 ERROR 1062 (23000): Duplicate entry '5' for key 'PRIMARY' 的报错。
所以双主不是“主从配两遍”，而是必须打破自增ID的默认行为：
-
auto-increment-increment = 2：步长设为 2 -
auto-increment-offset = 1（主A）和auto-increment-offset = 2（主B）：起始值错开 - 两台机器的
server-id绝对不能相同，且不能为 0 或 1（建议用 101、102 这类明确标识）
如何验证复制通道是否真正双向可用
只在从库执行 SHOW SLAVE STATUS\G 不够。双主要求两端都既是 Master 又是 Slave，因此每台机器上都要检查自己的复制状态，且重点看三个字段：
-
Slave_IO_Running: Yes：表示能连上对方并拉取 binlog -
Slave_SQL_Running: Yes：表示本地 SQL 线程能正常重放中继日志 -
Seconds_Behind_Master: 0：说明没有延迟积压（非 0 时要查Relay_Log_Space和网络延迟）
更关键的是：分别在 A 和 B 上插入带自增主键的新记录，立刻去对方查是否存在。不要只查一次，建议连续插 3–5 条，因为偶发的网络抖动或锁等待可能导致某条语句延迟同步。
Keepalived 虚拟 IP 切换时 MySQL 实际能否无缝接管
不能。Keepalived 只管 VIP 漂移，它不感知 MySQL 复制是否健康。如果 A 节点宕机前复制已中断（比如 B 的 Slave_SQL_Running 早就是 No），VIP 漂到 B 后，应用连过去写的全是“脏数据”——B 并不知道自己已经落后于 A 的最新状态。
所以必须加一层检测逻辑：
- Keepalived 的
vrrp_script里不能只检查mysql -e "SELECT 1"，而要执行：mysql -e "SHOW SLAVE STATUS\G" | grep -E "(Slave_IO_Running|Slave_SQL_Running): Yes" | wc -l - 返回值必须为 2 才认为节点可接管 VIP
- 同时禁用
read_only=OFF的自动写入权限，只在确认自身是“最新主库”时才放开（可通过比较Exec_Master_Log_Pos和对方的Read_Master_Log_Pos判断）
双主模式下哪些操作仍需人工干预
DDL（如 ALTER TABLE）、跨库事务、TRUNCATE、CREATE TEMPORARY TABLE 这些操作在双主中极难安全同步，MySQL 官方也不保证其一致性。尤其 TRUNCATE 在 binlog 中是 DDL，但某些版本会以 statement 格式记录，导致在另一端执行时报错或静默失败。
真实生产中，这类操作必须：
- 提前停写，选一个节点执行，等同步完成后再切回
- 禁用
binlog_format=STATEMENT，统一用MIXED或ROW - 在应用层加开关控制写入路由，避免误写到未同步完成的节点
别指望双主能全自动兜底所有操作——它解决的是单节点宕机时的快速服务恢复，不是替代运维判断的银弹。
