mysql新旧版本间不能双向同步，因复制协议仅单向兼容：5.7→8.0可行，8.0→5.7必然失败，因5.7无法解析8.0新增系统表、caching_sha2_password插件及原子ddl日志格式，配置再细也无法绕过此硬限制。
MySQL 新旧版本之间不能配置双向同步来实现平滑切换。这是由复制协议的单向兼容性决定的硬限制，不是配置技巧能绕过的。
MySQL 5.7 → 8.0 复制能跑通，但反向必然失败
-
MySQL 8.0的复制线程可以解析5.7生成的ROW格式 binlog、GTID 和事件结构； -
MySQL 5.7完全无法识别8.0引入的关键变更：- 新增系统表（如
mysql.role_edges） - 默认认证插件
caching_sha2_password - 原子 DDL 日志格式
- 新增系统表（如
- 一旦
8.0主库执行了含上述特性的操作，5.7从库会立即报错中断，典型错误包括：Unknown system tableUnsupported authentication pluginInvalid event type in binary log
所以所谓“双向同步”，在跨版本场景下本质是伪命题：你配得再细，START SLAVE 在 5.7 上面对 8.0 的 binlog 也会直接拒绝。
change master to 配置时最容易被忽略的三个运行时陷阱
仅改 my.cnf 不够，这些必须在启动后用 SQL 显式验证：
-
server_id必须全局唯一且非 0：执行SELECT @@server_id;确认，不能只看配置文件 -
binlog_format必须为ROW：5.7 默认已是，但若曾手动改过，需重设并重启；8.0 从库即使不开启log_bin，也建议显式设为ROW -
skip_log_bin在 8.0 中默认开启：如果误启了log_bin却没配server_id，复制线程会静默拒绝连接主库，错误日志里只显示ERROR 2003 (HY000): Can't connect to MySQL server，实际是权限/配置校验失败，不是网络问题
切换前必须做的三步验证，比 Seconds_Behind_Master = 0 重要得多
很多人看到复制延迟为 0 就切流量，结果发现数据已错位：
- 执行
pt-table-checksum对比主从关键表（尤其是大表）的行数与校验和，Seconds_Behind_Master = 0只说明 SQL 线程追到了中继日志末尾，不代表数据一致 - 检查
SHOW SLAVE STATUS\G中的Retrieved_Gtid_Set和Executed_Gtid_Set是否完全相等（启用 GTID 时），否则存在未执行的事务 - 登录 8.0 从库，手动执行几条业务高频查询（如按时间范围查订单、统计用户活跃数），与 5.7 主库结果逐字段比对，确认无隐式类型转换、默认值、JSON 字段解析等差异
真正的平滑切换，靠的是单向复制 + 人工校验 + 流量灰度，不是靠“双向”幻觉。版本差越大的环境，越要放弃对对称机制的执念。
