双主架构必须调 auto_increment_offset 和 auto_increment_increment，因为默认两节点均从1开始、步长为1，会导致同时插入时主键冲突；需设 increment=2、offset分别为1和2以错开序列。
为什么双主架构必须调 auto_increment_offset 和 auto_increment_increment
MySQL 8.0 双主（Active-Active）下不调整这两个参数，插入自增主键时必然冲突。因为两台机器默认都从 1 开始、步长为 1，INSERT 同时发生就会生成相同 ID，导致复制中断或主键冲突错误：ERROR 1062 (23000): Duplicate entry 'X' for key 'PRIMARY'。
核心逻辑是让两节点的自增序列“错开”：比如 A 节点生成 1, 3, 5…，B 节点生成 2, 4, 6…，这样即使同时插入也不会撞。
实操建议：
- 两节点统一设
auto_increment_increment = 2（步长为 2） - A 节点设
auto_increment_offset = 1，B 节点设auto_increment_offset = 2 - 必须在
my.cnf中配置并重启 mysqld，仅用SET GLOBAL无法持久化，且复制线程启动前就已读取变量值 - 注意：该设置只影响新插入的自增 ID，不影响已有数据；如果表已存在大量数据，需确保最大 ID 不与未来生成序列重叠（例如 A 当前最大 ID 是 99，它下次会插 101，没问题；但如果 B 最大 ID 是 100，它下次插 102，也安全）
配置文件里怎么写才真正生效
直接改 my.cnf 的 [mysqld] 段，别漏掉任一节点。配置项必须写在服务启动前，且不能被 !include 或环境变量覆盖。
示例（A 节点）：
[mysqld] server-id = 1 log-bin = binlog binlog-format = ROW auto-increment-offset = 1 auto-increment-increment = 2
示例（B 节点）：
[mysqld] server-id = 2 log-bin = binlog binlog-format = ROW auto-increment-offset = 2 auto-increment-increment = 2
关键检查点：
- 重启后执行
SHOW VARIABLES LIKE 'auto_increment%';确认值已加载 - 确认
server-id全局唯一，否则 GTID 或基于位置的复制会拒绝连接 - 如果启用了 GTID（推荐），还需额外配置
gtid_mode = ON、enforce_gtid_consistency = ON，且双主间需启用log_slave_updates = ON
双主同步失败时，auto_increment 参数还管用吗
不管用。一旦复制中断（比如网络闪断、SQL 线程报错停住），两节点各自继续写入，自增 ID 序列就不可控了。此时即使参数正确，也无法避免后续冲突。
所以双主不是“配完参数就高可用”，而是一个脆弱模式，必须配套监控和快速干预机制：
- 用
SHOW SLAVE STATUS\G检查Seconds_Behind_Master、SQL_Thread_State、Retrieved_Gtid_Set和Executed_Gtid_Set是否一致 - 禁止在业务高峰期手动
STOP SLAVE; START SLAVE;，容易引发 GTID 执行集错乱 - 不要依赖
auto_increment做分库分表路由——它只是防冲突兜底，不是设计依据 - 真实生产环境更倾向用 MHA + 单主，或直接切到 MySQL Group Replication / InnoDB Cluster
有没有比双主更稳妥的替代方案
有，而且强烈建议优先考虑：MySQL Group Replication（MGR）是 MySQL 8.0 原生支持的多主/单主模式，自动处理冲突检测、事务认证、故障自动剔除，不需要手调 auto_increment 参数。
如果必须双主，至少做到：
- 所有写请求走中间件（如 ProxySQL、ShardingSphere）做读写分离，并严格限制写只打到一个主（即伪双主，另一主仅热备）
- 禁用双向同步的 DML 写入，只允许应用层明确指定写入节点
- 定期校验双节点数据一致性（用
pt-table-checksum），而不是依赖“参数设对了就没事”
最常被忽略的一点：双主的“高可用”假象来自切换快，但代价是数据一致性风险陡增。只要有一条事务在复制中断期间被跳过，auto_increment 再精确也救不回丢失的业务语义。
