MySQL 双主必须设 auto_increment_offset 和 auto_increment_increment，否则自增 ID 必然冲突；应设 increment=2、offset 分别为 1 和 2，并在 my.cnf 配置后重启。
MySQL 双主为什么必须调 auto_increment_offset 和auto_increment_increment
不设这两个参数，双主写入必然主键冲突——哪怕只有一边在写，另一端也可能因复制延迟或手动干预产生重复 ID。INSERT语句用自增主键时，MySQL 不会跨实例协商 ID，只按本地配置生成。默认都是1，结果两边都插1,2,3……，一同步就Duplicate entry '2' for key 'PRIMARY'。
实操建议：
- 设
auto_increment_increment = 2（步长为 2），确保两台机器生成的 ID 天然错开 - 一台设
auto_increment_offset = 1（生成 1,3,5…），另一台设offset = 2（生成 2,4,6…） - 必须在
my.cnf里配，且需重启生效；运行时用SET GLOBAL改只对新连接有效，复制线程可能仍用旧值 - 注意：如果未来要加第三台主库，得提前把
increment改成 3，并重新分配offset，否则扩容即崩
双向同步不是配两个 CHANGE MASTER TO 就完事
MySQL 原生不支持“自动双向复制”。所谓双主，本质是两套独立的主从关系反向配置：A→B 和 B→A。但复制链路一旦中断、延迟或误操作，极易形成“循环写入”——比如 A 写一条记录，同步到 B，B 又把它当作新事件发回 A，A 再同步回去，无限套娃。
实操建议：
- 必须开启
log_slave_updates = ON，否则从库不记录接收到的 binlog，无法继续向下游转发 - 务必设置
replicate_same_server_id = OFF（默认就是 OFF），否则同 server_id 的事件会被直接忽略，导致同步断掉 - 用
replicate_ignore_db或replicate_do_table过滤掉复制自身产生的变更（如监控表、心跳表），减少循环风险 - 强烈建议在 SQL 线程启动前，先执行
SET SQL_LOG_BIN = 0临时关 binlog，避免把建用户、改权限这类管理操作也同步过去
Duplicate entry错误出现后，不能直接SET GLOBAL sql_slave_skip_counter = 1
跳过一个 event 看似快，但极大概率让主从数据永久不一致。比如跳过的那条是UPDATE t SET x=1 WHERE id=100，而实际业务中 id=100 这行后来又被删了，跳过后 A 有 x =1、B 没有，再也追不平。
实操建议：
- 先停复制：
STOP SLAVE，再查SHOW SLAVE STATUSG确认出错位置（Exec_Master_Log_Pos） - 用
mysqlbinlog解析对应 binlog 文件，在出错位置前后人工比对 A / B 两端该行当前值，判断是否真冲突、还是只是顺序问题 - 若确认是自增 ID 冲突（如 B 上已存在 A 刚插入的 ID），可手动在 B 上
DELETE或UPDATE修正，再START SLAVE - 别依赖
slave_skip_errors全局跳错，它会掩盖更深层的同步断裂
双主架构下 INSERT …… SELECT 和REPLACE INTO最危险
这类语句在复制时容易触发非确定性行为。比如 INSERT INTO t1 SELECT * FROM t2，如果 t2 在 A / B 两端内容不同（哪怕只差一行），插入结果就不同；REPLACE INTO 本质是DELETE + INSERT，在双主下可能被两边各自执行一次，导致数据清空又重建两次。
实操建议：
- 禁止在双主环境用
INSERT …… SELECT跨表批量写入，改用应用层分页 + 单条INSERT -
REPLACE INTO全部换成INSERT …… ON DUPLICATE KEY UPDATE，后者只在冲突时更新，不引发额外删除 - 所有带
UUID()、NOW()、RAND()等函数的语句，必须显式指定值，否则主从生成结果不同 - DDL 操作（如
ALTER TABLE）务必在维护窗口内单点执行，切勿两边同时跑
双主真正的难点不在配置，而在“谁写哪张表”“什么操作绝对不能做”这些约束必须刻进开发和 DBA 肌肉记忆里。漏一条，后面排查三天都不见得能还原现场。
