安全路径唯一：5.7主→8.0从，反向不可行；必须确认主库gtid状态并统一配置，主库设binlog_format=row+binlog_row_image=full，从库强制binlog_row_metadata=none、禁用binlog_transaction_compression，复制用户须显式指定mysql_native_password插件，初始同步必须用mysqldump逻辑备份并校验一致性。
跨版本主从复制升级在生产环境只有一条安全路径：5.7 主 → 8.0 从，反向绝对不可行。任何试图让 8.0 做主、5.7 做从的配置，启动 START REPLICA 就会失败，且无法修复。
确认主库是 5.7 且已开启 GTID（或明确关闭）
这是最常被跳过却直接导致复制卡死的环节。8.0 从库对 GTID 状态极其敏感，而 5.7 主库默认可能未启用 GTID（尤其老版本或未升级到 5.7.29+）。必须在主库和从库上分别执行：
SELECT @@gtid_mode, @@enforce_gtid_consistency, @@binlog_format, @@server_id;
若主库返回 gtid_mode=OFF，从库也必须设为 OFF，不能用 AUTO_POSITION=1；若主库已开 GTID，则需检查 SHOW MASTER STATUS 中的 Executed_Gtid_Set 是否与 binlog 文件范围一致——不一致时，优先在主库执行：SET GLOBAL enforce_gtid_consistency = OFF; → SET GLOBAL gtid_mode = OFF_PERMISSIVE; → SET GLOBAL gtid_mode = OFF;，再重启复制链路。
主库配 ROW + FULL，从库强制禁用 binlog_row_metadata
8.0 默认启用 binlog_row_metadata=FULL，它会在 row event 中插入表元数据哈希，5.7 主库完全不识别这个字段，但问题出在——8.0 从库自己生成的中继日志（relay log）也会带该字段，导致后续如果做级联复制或故障切换，下游解析直接报 Unknown binlog event type。
所以必须显式干预：
- 主库（5.7）确保：
binlog_format=ROW且binlog_row_image=FULL（避免部分更新引发列偏移） - 从库（8.0）配置文件中必须写：
binlog_row_metadata=NONE（不能依赖默认值） - 验证命令：
SELECT @@binlog_row_image, @@binlog_row_metadata;—— 主库应为FULL/FULL，从库应为FULL/NONE
另外注意：8.0.33+ 默认开启 binlog_transaction_compression，若主库没开压缩而从库开了，IO_THREAD 会静默失败，务必在从库关掉：binlog_transaction_compression=OFF。
创建复制用户时必须指定 mysql_native_password
MySQL 8.0 默认认证插件是 caching_sha2_password，而旧版 JDBC/ODBC 驱动（尤其未更新到 8.0-compatible 版本的）连接时会卡在 AUTH 或报 Access denied for user。这不是权限问题，是协议握手失败。
解决方式只有一种：主库上创建用户时显式指定旧插件：
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';
切记不要用 ALTER USER 'repl'@'%' IDENTIFIED BY 'xxx'; —— 它默认沿用当前用户的 plugin，很可能悄悄把认证方式切回 caching_sha2_password，导致某天凌晨突然断连。
同步前必须做逻辑备份并校验 checksum
物理备份（如 xtrabackup）在跨版本场景下风险极高：8.0 的数据字典格式与 5.7 不兼容，直接拷贝 .ibd 文件大概率启动失败。唯一稳妥路径是 mysqldump 导出 + 导入。
但 dump 本身不保证一致性，必须加关键参数：
-
--single-transaction（确保 InnoDB 表一致性） -
--routines --triggers --events（导出存储过程、触发器、事件） -
--master-data=2（嵌入CHANGE MASTER TO所需的 binlog 位置）
导入后，别急着启复制。先在主从两端跑一遍 SELECT COUNT(*) FROM table_name; 对比关键表行数，再用 pt-table-checksum（Percona Toolkit）做逐行校验——很多“看起来同步了”的实例，其实早就在某次大事务后开始丢数据，只是没暴露。
真正麻烦的从来不是配置命令是否敲对，而是那些没报错却持续静默偏移的数据不一致。上线前多花十分钟校验，比半夜翻 error.log 强十倍。
