必须配对设置auto_increment_increment和auto_increment_offset，否则双主自增ID必然冲突；A设increment=2/offset=1生成奇数ID，B设increment=2/offset=2生成偶数ID，且须写入my.cnf[mysqld]段并重启生效。
为什么双主必须设 auto_increment_increment 和 auto_increment_offset
不设就必然冲突。MySQL 8.0 默认两个节点的自增 ID 都从 1 开始、步长为 1，只要两边同时执行 INSERT INTO t () VALUES ()，就大概率生成相同主键，触发 ERROR 1062 (23000): Duplicate entry 'X' for key 'PRIMARY'，复制直接中断。
核心不是“避免重复”，而是让两节点的自增序列天然错开：A 节点只产奇数（1, 3, 5…），B 节点只产偶数（2, 4, 6…）。这需要两个参数协同生效：
-
auto_increment_increment = 2：统一设为 2，保证每次跳 2 -
auto_increment_offset：A 设 1，B 设 2，决定起始点
配置必须写在 my.cnf 里，SET GLOBAL 无效
这两个变量是只读启动参数，SET GLOBAL auto_increment_increment = 2 看似成功，但重启后丢失，且复制线程启动时已按配置文件值初始化了内部计数器，运行时改没用。
正确做法是编辑每个节点的 my.cnf（Linux）或 my.ini（Windows）的 [mysqld] 段：
[mysqld] server-id = 1 log-bin = mysql-bin binlog-format = ROW auto-increment-offset = 1 auto-increment-increment = 2
另一节点 offset 改为 2，其余一致。改完必须重启 mysqld，不能只 reload。
验证是否生效：SHOW VARIABLES LIKE 'auto_increment%'; —— 必须看到实际值，而不是默认值。
已有数据时，offset 设置要避开当前最大 ID
该设置只影响后续新插入的行，不重排历史数据。但如果你的表当前最大 ID 是 99，而你把 A 节点设为 offset = 1, increment = 2，它下次插入就是 101，安全；但如果 B 节点当前最大 ID 是 100，它设 offset = 2 后下一个是 102，也安全。
真正危险的是：某节点当前最大 ID 是偶数，却配了 offset = 1；或当前最大 ID 是奇数，却配了 offset = 2。例如：
- B 节点当前最大 ID 是 99（奇数），但配了
offset = 2→ 下次插 100 → 冲突！ - A 节点当前最大 ID 是 100（偶数），但配了
offset = 1→ 下次插 101 → 表面安全，但若 B 同时插 100 就炸了
所以操作前先查：SELECT MAX(id) FROM your_table;，确保每个节点的 offset 与当前最大 ID 的奇偶性一致。
GTID 模式下，log_slave_updates = ON 是硬性要求
双主用 GTID（强烈推荐）时，仅设 offset/increment 不够。因为 GTID 复制依赖事务全局唯一标识，而 slave 要把收到的事务再转发给另一个 master，就必须开启 log_slave_updates = ON，否则第二个节点收不到第一个节点写入的事务，同步链就断了。
完整 GTID 必备项（两节点都配）：
gtid_mode = ONenforce_gtid_consistency = ONlog_slave_updates = ON
漏掉 log_slave_updates，SHOW SLAVE STATUS\G 里 Retrieved_Gtid_Set 和 Executed_Gtid_Set 会不一致，且 Seconds_Behind_Master 持续增长，最终复制停滞。
auto_increment 参数只是防冲突的第一道防线；一旦网络分区或复制中断，两节点各自写入，序列就不可控了——这时候靠的是上层应用限流、VIP 切换策略、或者直接停写一端，而不是指望数据库自己“智能避让”。 
