mysql主从复制仅支持低版本主库→高版本从库的单向降级兼容，反向绝对不可行；需严格统一binlog_format、gtid_mode、sql_mode等关键参数，并遵循“先升从库再升主库”操作顺序。
MySQL主从复制支持跨版本吗？答案很直接：只支持单向降级兼容
低版本主库 → 高版本从库，可以；反过来绝对不行。比如 MySQL 5.7 主库往 MySQL 8.0 从库同步？官方明确不支持——8.0 的 binlog_format=ROW 默认用 Write_rows_v2 事件，而 5.7 无法解析，从库 IO 线程会卡死在 Connecting to master 或报错 Unknown binlog event type。
-
MySQL 5.6主 →8.0从：不可行，必须经5.7桥接（即 5.6→5.7→8.0） -
5.7主 →8.0从：可行，但需确认binlog_format和sql_mode兼容，尤其避免ONLY_FULL_GROUP_BY在从库触发 SQL 错误 - 版本号差异尽量控制在「前两位相同」，例如
8.0.33和8.0.36安全；8.0和5.7虽同属“大版本跨度”，但方向错了就彻底失败
配置时最容易被忽略的三个兼容性开关
光版本对还不行，关键参数不一致照样同步中断。这些不是可选优化项，是跨版本复制的生存底线：
-
binlog_format必须设为ROW（推荐）或MIXED，严禁STATEMENT—— 高版本新增函数（如JSON_CONTAINS）在低版本从库上无法重放 -
gtid_mode：若主库启用了 GTID（gtid_mode=ON），从库也必须开启且enforce_gtid_consistency=ON；否则CHANGE MASTER TO会拒绝执行 -
sql_mode建议主从完全一致，尤其注意STRICT_TRANS_TABLES、NO_ZERO_DATE等——主库插入一条宽松模式下的日期，从库严格模式下直接报错中断 SQL 线程
数据初始化阶段的坑：mysqldump 不等于万能
用 mysqldump 导出低版本主库再导入高版本从库，看似稳妥，实则暗藏两处断裂点：
- 导出时没加
--set-gtid-purged=OFF（针对 GTID 环境），会导致导入后从库的gtid_executed与主库位点错乱，START SLAVE直接失败 - 没过滤掉高版本特有系统表（如
mysql.role_edges、mysql.password_history），导入时可能因表结构不匹配报错，尤其5.7 → 8.0场景 - 更稳妥的做法：停写主库，
FLUSH TABLES WITH READ LOCK+SHOW MASTER STATUS记下位点，再mysqldump --single-transaction --master-data=2，导入后用CHANGE MASTER TO ... MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy精确对接
升级主库前，必须先升从库
这是线上最常翻车的操作顺序。比如计划把主库从 5.7.40 升到 8.0.36，如果先升主库，所有 5.7 从库立刻断连，且无法恢复——因为新版主库生成的 binlog，老从库根本看不懂。
- 正确顺序：
5.7从库 → 升级为8.0→ 验证复制正常 → 再升级原主库（此时它变成新8.0从库）→ 最后切换角色 - 升级过程中，务必检查
slave_sql_running_state是否卡在Waiting for table metadata lock——这往往是因为主库升级后加了新字段，而从库还没完成 DDL 同步 - 跨大版本升级后，首次启动从库建议加
--skip-slave-start，手动START SLAVE并观察SHOW SLAVE STATUS\G中的Seconds_Behind_Master和SQL_Delay是否异常跳变
版本差得越远，配置项和 binlog 事件的隐性差异就越难排查。别指望“试一下”，得把 server_id、log_bin、relay_log、read_only 这些基础项全部列出来逐条比对——人在紧张时，最容易漏掉 log_slave_updates = ON 这种看起来无关紧要、实则决定能否级联的关键开关。
