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 STATUS\G确认出错位置（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肌肉记忆里。漏一条，后面排查三天都不见得能还原现场。
