MySQL 5.7主库配8.0从库可行，但需绕过认证插件（8.0默认caching_sha2_password，5.7从库不识别）、半同步参数名冲突（如rpl_semi_sync_source_enabled）、GTID不兼容（5.7未开GTID时禁用MASTER_AUTO_POSITION=1）及正确设置file+position位点等关键陷阱。
MySQL 5.7 主库配 MySQL 8.0 从库是可行的，但必须手动绕过几个关键兼容性陷阱；反过来（8.0 主 → 5.7 从）则直接不支持，因为 5.7 解析不了 8.0 的新 binlog 事件格式和认证协议。
change master to 执行失败：主从版本握手阶段就卡住
常见错误：ERROR 2003 (HY000): Can't connect to MySQL server on 'xxx' 或更隐蔽的 ERROR 1045 (28000): Access denied for user，其实不是密码错，而是认证插件不兼容。
-
MySQL 8.0默认使用caching_sha2_password插件，而MySQL 5.7客户端（包括 5.7 作为从库时内置的复制客户端）压根不认识它 - 解决方案不是降级主库认证，而是在 8.0 从库上显式指定用旧插件连接主库
- 在 8.0 从库执行：
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'your_pass';
- 然后
GRANT REPLICATION SLAVE ON <em>.</em> TO 'repl'@'%'; - 主库（5.7）无需改任何配置，它只管发 binlog
别漏掉：主库 my.cnf 必须启用 log-bin 和唯一 server-id，从库（8.0）的 server-id 要不同且非 0。
START SLAVE 后 IO_THREAD 一直 Connecting 或报 Unknown system variable 'rpl_semi_sync_source_enabled'
这是典型的参数透传污染：如果主库开了半同步，它的某些全局变量会随 handshake 发送给从库，而 5.7 主库的半同步变量名（如 rpl_semi_sync_master_enabled）和 8.0 从库期待的（rpl_semi_sync_source_enabled）不一致，导致初始化失败。
- 关键动作：在 8.0 从库启动复制前，临时禁用所有半同步相关变量加载
- 启动 8.0 从库时加参数：
--skip-rpl-semi-sync，或在my.cnf中写：loose-rpl-semi-sync-source-enabled = OFF
- 同时确认从库没开启
enforce_gtid_consistency=ON（除非主库也开 GTID），否则START SLAVE会直接拒绝——5.7 主库若没开 GTID，8.0 从库就不能强制要求 GTID 一致性
Seconds_Behind_Master 持续增长，但 Retrieved_Gtid_Set 和 Executed_Gtid_Set 都为空
说明复制根本没跑进 GTID 流程，问题出在初始位点设置环节。
- 5.7 主库默认不开启 GTID，所以你不能在
CHANGE MASTER TO里写MASTER_AUTO_POSITION=1 - 必须用传统 file+position 方式：
CHANGE MASTER TO MASTER_HOST='5.7-master-ip', MASTER_USER='repl', MASTER_PASSWORD='your_pass', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;
- 获取
MASTER_LOG_FILE和MASTER_LOG_POS必须在主库执行SHOW MASTER STATUS，且该位置要早于你导出数据的时间点（如果你用了 mysqldump，记得加--master-data=2参数自动注入）
注意：8.0 从库即使没开 GTID，SHOW SLAVE STATUS 里仍会显示 Retrieved_Gtid_Set 字段，但它为空是正常的——别被字段名骗了。
主从异步复制跨大版本最危险的地方不在配置本身，而在于「你以为同步成功了，其实 SQL 线程早就静默停了」。务必在 START SLAVE 后立刻查 SHOW SLAVE STATUS\G，重点盯三个字段：Slave_IO_Running: Yes、Slave_SQL_Running: Yes、Seconds_Behind_Master: 0 —— 少一个都不算真正跑起来。
