mysql 8.0 主库 + 5.7 从库官方明确禁止，因 8.0 引入 write_rows_v2、table_map_v2 等新事件类型及 binlog_row_metadata=full，5.7 解析器无法识别，直接报 unknown binlog event type，属二进制协议断层，不可通过参数调优绕过。
跨大版本主从复制不是“不建议”，而是官方明确禁止高版本主库 → 低版本从库，且低→高也必须严格约束条件；Binlog格式不兼容是其中最硬的卡点，不是配置能绕开的底层解析失败。
MySQL 8.0 主库 + 5.7 从库为什么直接报 Unknown binlog event type
8.0 默认启用 binlog_row_image=FULL 和 binlog_row_metadata=FULL，并引入 Write_rows_v2、Table_map_v2 等新事件类型。5.7 的 binlog 解析器根本没见过这些结构，IO 线程一读就崩，日志里固定出现：
Got fatal error 1236 from master when reading data from binary log: 'Unknown binlog event type'
这不是参数调优问题，是二进制协议层面的断层。即使你把 binlog_format 改成 ROW，也无法让 5.7 理解 8.0 的事件头字段布局。
- 5.7 无法识别 8.0 新增的
source_id扩展字段（GTID 相关） -
binlog_checksum=CRC32在 5.7.29+ 才支持，老版本会直接拒绝连接 - 8.0 默认开启
enforce_gtid_consistency=ON，而 5.7 对某些非事务语句（如CREATE TEMPORARY TABLE）无法生成合法 GTID，导致 SQL 线程拒绝执行
5.7 主 → 8.0 从看似可行，但实际要过三道关
方向对了只是起点，mysqldump 导出再导入、CHANGE MASTER TO 配上位点，照样可能在 START SLAVE 后几秒内失败。关键卡点不在 SQL 层，而在 binlog 解析与应用链路：
-
binlog_row_image必须设为FULL：8.0 默认值已是 FULL，但若主库曾手动改过，需确认；否则部分更新（如只改一个字段）会导致从库列偏移错乱 -
binlog_row_metadata必须关掉：SET GLOBAL binlog_row_metadata = OFF，否则 8.0 发送的元数据包含 5.7 不认识的字段，IO 线程卡在Connecting to master -
sql_mode必须对齐：尤其STRICT_TRANS_TABLES和NO_ZERO_DATE，主库插入的宽松日期（如'0000-00-00'）在 8.0 从库严格模式下直接触发ER_BAD_NULL_ERROR
mysqldump 初始化时最容易漏掉的两个 --set-gtid-purged 陷阱
用 mysqldump 做初始数据同步，不是加个 --master-data=2 就万事大吉。GTID 环境下，导出文件头部的 SET @@GLOBAL.GTID_PURGED 语句会直接决定从库后续能否接上主库 binlog 流：
- 如果主库启用了 GTID（
gtid_mode=ON），但导出时没加--set-gtid-purged=OFF，dump 文件会写入当前gtid_purged值——导入后从库的gtid_executed被强制覆盖，和主库位点彻底错位，START SLAVE必报Error 1236 - 如果主库是 5.7、从库是 8.0，dump 文件里还可能包含 8.0 特有系统表（如
mysql.role_edges），导入时报Table doesn't exist或Unknown table engine 'InnoDB'，因为 5.7 没这些表结构定义
正确做法是：停写主库 → FLUSH TABLES WITH READ LOCK → SHOW MASTER STATUS 记下 file/pos → mysqldump --single-transaction --master-data=2 --set-gtid-purged=OFF --skip-triggers --no-routines → 导入后手动 CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy。
升级顺序错了，整个复制链就废了
线上最常翻车的操作是：先升主库到 8.0，再慢慢升从库。结果是——所有 5.7 从库瞬间断连，且无法恢复。因为新版主库产生的 binlog，老从库解析器根本不认识，Slave_IO_Running 永远卡在 Connecting 或报错退出。
唯一安全路径是「先升从库，再升主库」，且中间不能留空窗期。例如计划从 5.7.40 升级到 8.0.36：
- 第一步：把全部从库升级到 8.0.36，并验证
START SLAVE成功、Seconds_Behind_Master=0 - 第二步：停写主库，升级主库到 8.0.36，启动后立即检查
SHOW MASTER STATUS和SHOW SLAVE STATUS是否正常 - 第三步：观察所有从库 IO/SQL 线程是否持续运行，不要依赖“看起来没报错”——要盯
Retrieved_Gtid_Set和Executed_Gtid_Set是否在增长
真正难的不是命令怎么敲，而是所有节点的 binlog_format、gtid_mode、sql_mode、binlog_row_image 这几个开关必须在升级前就对齐，且不能只看配置文件——得用 SELECT @@variable_name 实时查运行值。
