主主复制必须配置server-id、auto_increment_offset和log_slave_updates三者成对错开，否则必然主键冲突或同步中断：Server A设server-id=1、offset=1、increment=2，生成奇数ID；Server B设server-id=2、offset=2、increment=2，生成偶数ID；且两端均需启用log_slave_updates=1，确保双向binlog传播。
不能直接用默认配置搭主主复制，server-id、auto_increment_offset、log_slave_updates 这三项不配对，复制必然中断或主键冲突。
为什么 server-id 和自增参数必须成对错开
两台 MySQL 实例若都用 auto_increment_increment = 1，又没设 offset，插入新记录时会生成相同主键，造成同步失败（错误如 ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'）。server-id 不唯一则复制线程无法区分来源，log_slave_updates 关闭会导致从库收到的变更不写入自身 binlog，另一端就收不到——双向链路直接断掉。
必须这样配：
- Server A：
server-id = 1，auto_increment_offset = 1，auto_increment_increment = 2 - Server B：
server-id = 2，auto_increment_offset = 2，auto_increment_increment = 2
这样 A 生成 ID：1, 3, 5…，B 生成 ID：2, 4, 6…，物理上避开冲突。
log_slave_updates 是双向同步的开关
它控制“从库应用的事件是否记入自己的 binlog”。主主架构里，A 是 B 的主库，B 同时也是 A 的主库——所以 B 必须把从 A 拉来的变更再写进自己的 binlog，否则 A 就无法作为从库去拉 B 的更新。漏掉这行，SHOW SLAVE STATUS 里 Seconds_Behind_Master 可能为 0，但实际数据早已不同步。
确认方式：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 登录任一节点执行
SELECT @@log_slave_updates;，返回 1 才有效 - 配置文件中必须显式写
log_slave_updates = 1，MySQL 8.0 默认关闭，5.7 默认关闭 - 改完要重启 mysqld，仅
SET GLOBAL不生效
GTID 模式下 change master to 必须带 master_auto_position = 1
启用 GTID（gtid_mode = ON）后，不能再靠 MASTER_LOG_FILE 和 MASTER_LOG_POS 定位，否则会报错 ERROR 1236 (HY000): Got fatal error 1236 from master。必须用 GTID 自动定位：
CHANGE MASTER TO MASTER_HOST='192.168.4.52', MASTER_USER='repluser', MASTER_PASSWORD='Abc-1234', MASTER_AUTO_POSITION = 1;
注意点：
- 两台都要开
enforce_gtid_consistency = TRUE，否则建表含非确定性函数（如UUID()）会拒绝执行 -
RESET MASTER会清空 GTID_EXECUTED，主主环境下严禁在已运行节点执行 - 首次配置建议用
mysqldump --set-gtid-purged=ON导出，否则导入后 GTID 不连续
检查 SHOW SLAVE STATUS 时重点盯哪几项
不是只看 Slave_IO_Running 和 Slave_SQL_Running 都是 Yes 就完事。真正容易被忽略的是：
-
Seconds_Behind_Master：长期 > 0 表示延迟，但值为 0 不代表实时——可能卡在某个事务里 -
Exec_Master_Log_Pos和Read_Master_Log_Pos差距大，说明 IO 线程拉得快、SQL 线程执行慢 -
Last_IO_Errno/Last_SQL_Errno为 0 才安全；非 0 时要看Last_IO_Error具体内容（比如网络超时、权限拒绝、表不存在） -
Retrieved_Gtid_Set和Executed_Gtid_Set应完全一致，否则有 GTID 跳过或执行失败
主主最脆弱的地方不在配置阶段，而在上线后——应用层若没做写请求路由隔离，两个节点同时 INSERT 同一张表的同一业务逻辑，即使 ID 不冲突，UPDATE 或 DELETE 也可能因执行顺序不一致导致最终状态错乱。这点没法靠数据库配置解决，得靠应用兜底。
