mysql 8.0双向复制不能用于无缝升级，因其本质是同版本数据同步；真正无缝升级需先建5.7→8.0单向复制并验证一致，再启用反向复制形成双向链路以支持滚动切换角色。
MySQL 8.0 双向复制不能用于“无缝升级”本身，它只是数据同步手段；真正实现平级版本（如 5.7→8.0）无缝升级，靠的是先建好双向复制链路，再滚动切换角色，而非靠复制机制自动升级版本。
为什么不能直接用双向复制完成版本升级
双向复制（Master-Master）本质是两个同版本 MySQL 实例互为 master/slave，它们之间同步的是 binlog 事件。但 MySQL 5.7 和 8.0 的 binlog 格式、GTID 行为、系统表结构、默认认证插件（mysql_native_password vs caching_sha2_password）均不兼容。强行让 5.7 主库连 8.0 从库，START SLAVE 会直接报错，常见错误如：
-
ERROR 1236 (HY000): Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'（GTID 不连续） -
ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded（认证插件不识别） -
Replicate_Wild_Ignore_Table或binlog_format不一致导致 SQL 线程中断
真正的平级升级路径：先搭双主，再换实例
所谓“平级无缝”，是指业务不中断、IP/端口/连接串不变，靠的是在旧版本节点仍在线时，提前部署新版本节点并建立复制，最后仅做一次角色切换。关键不在“双向”，而在“滚动替换”：
- 必须分两阶段：先让 5.7 → 8.0 单向复制跑稳（用
mysqldump+mysqlbinlog或工具如NineData做初始同步+增量追赶），确认Seconds_Behind_Master = 0且无SQL_Errno - 再在 8.0 节点上启用
log_slave_updates = ON，并配置反向复制（8.0 → 5.7），此时才是“双向”——但仅用于倒切回滚或读写分流，不是升级动作本身 - 切换时，先停写旧主（5.7），等其 binlog 全部被 8.0 消费完（
Retrieved_Gtid_Set = Executed_Gtid_Set），再将应用连接指向 8.0，并把原 5.7 改为只读从库 - 整个过程要求两端
server-id不同、gtid_mode = ON且enforce_gtid_consistency = ON——否则切换后无法保障事务一致性
auto_increment 配置是双向链路的生死线
一旦启用双向复制，auto_increment_increment 和 auto_increment_offset 就不是“建议设置”，而是强制前提。漏配或配错会导致 INSERT 不指定 ID 时主键冲突，且冲突不会报错，只会静默丢数据：
- 两节点都设
auto_increment_increment = 2 - Node A（原 5.7）设
auto_increment_offset = 1→ 生成 ID：1, 3, 5, 7… - Node B（新 8.0）设
auto_increment_offset = 2→ 生成 ID：2, 4, 6, 8… - 若误将两者 offset 都设为 1，同一张表在两边插入不带 ID 的记录，必然主键重复，
SQL Thread直接 stop，且错误日志里只有Duplicate entry '1' for key 'PRIMARY'，极易被忽略
验证是否真同步，别信 Slave_IO_Running: Yes
很多运维看到 SHOW SLAVE STATUS\G 里两个 Yes 就以为通了，其实只是线程活着。真正要确认数据级同步，必须查三处：
-
Seconds_Behind_Master必须稳定为0（非 NULL），且持续 5 分钟以上 -
Executed_Gtid_Set和Retrieved_Gtid_Set必须完全相等（GTID 模式下） - 手动在主库执行一条带唯一约束的 INSERT，立刻去从库查是否存在——不能只查 count(*)，要查具体值，因为可能 relay log 已写但 SQL thread 还没执行
最易被忽略的是：升级过程中，旧主（5.7）的 max_allowed_packet 或 wait_timeout 若比新主（8.0）小，会导致大事务或长连接中断复制，现象是 IO Thread 频繁重连，但状态始终显示 Yes。
