seconds_behind_master为null说明io线程未连接主库，通常因5.7主库使用caching_sha2_password而8.0从库不兼容，需在5.7主库配置default_authentication_plugin=mysql_native_password并重建复制用户。
SHOW SLAVE STATUS 里 Seconds_Behind_Master 是 NULL 怎么办
这不是延迟高，是 IO 线程根本没连上主库——大概率卡在认证握手阶段。别急着跳过错误，先看 Last_IO_Error 字段：Authentication plugin 'caching_sha2_password' cannot be loaded 就是典型症状。
原因很直接：5.7 主库 binlog 不带 caching_sha2_password 握手所需元数据，而 8.0 从库默认要求该插件。修复不是升级驱动，而是让主库彻底不用它：
- 在 5.7 主库
my.cnf中加default_authentication_plugin=mysql_native_password，重启服务 - 所有新建复制账号必须显式指定旧插件：
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 禁止在 5.7 主库执行
ALTER USER ... IDENTIFIED WITH caching_sha2_password，否则后续 binlog 事件会卡住 8.0 从库 SQL 线程
Retrieved_Gtid_Set 为空但 Executed_Gtid_Set 有值怎么修
这说明 GTID 已错乱，不是配置没开，而是状态已污染。常见于 mysqldump 导入后未清理自身 GTID 集合。
必须人工干预，不能靠 START SLAVE 自动恢复：
- 检查 5.7 主库是否真开了 GTID：
SELECT @@gtid_mode, @@enforce_gtid_consistency;若为OFF，从库也必须设为OFF，不能依赖AUTO_POSITION - 若主库确实关了 GTID，从库却残留了 GTID 状态，需先执行
RESET SLAVE ALL，再删掉mysql库下所有非 InnoDB 表（如plugin、servers），避免系统表结构冲突 - 导入 dump 后立刻执行
RESET MASTER，清空gtid_purged，否则与主库 GTID 集合无法对齐
IO 线程报 Unknown binlog event type 怎么定位
这是硬性协议断层，不是参数能绕开的。只可能出现在 8.0 主 → 5.7 从场景，官方明确禁止。
但如果你看到这个报错，说明方向错了——必须确认主从版本关系：
- 查主库版本：
SELECT VERSION();；查从库版本同理。若主库是 8.0、从库是 5.7，立刻停用，不可强撑 - 8.0 引入了
Write_rows_v2、Table_map_v2和binlog_row_metadata=FULL，5.7 解析器完全不认识这些结构 - 即使你把
binlog_format改成ROW，也无法让 5.7 理解 8.0 的事件头字段布局 - 唯一合法路径是 5.7 主 → 8.0 从，且从库必须设
binlog_row_metadata=NONE（通过配置或SET GLOBAL）
mysqldump 初始化后 START SLAVE 失败的隐藏坑
全量同步阶段最容易忽略的是 GTID 和初始化状态冲突，表面看配置都对，实则 dump 文件里埋了雷。
关键操作必须一步不漏：
- 5.7 主库导出时必须加
--set-gtid-purged=OFF，否则 dump 文件头部会写死SET @@GLOBAL.GTID_PURGED，8.0 从库导入后无法接续主库 binlog 流 - 导入完成后，立刻执行
RESET MASTER，清空从库自身的gtid_purged，否则与主库 GTID 集合冲突 - 启动复制前，确认主库
binlog_format=ROW且gtid_mode=OFF（官方仅支持 5.7→8.0 在 GTID 关闭状态下运行） - 每个参数变更都要双向验证：
sql_mode、lower_case_table_names、binlog_checksum必须严格一致，改一头不改另一头，照样卡在 SQL 线程
真正麻烦的从来不是单个参数，而是这些修改必须在主从两端严格同步生效——比如主库改了 default_authentication_plugin，但从库没同步更新 sql_mode 去掉 ONLY_FULL_GROUP_BY，遇到含分组查询的 binlog 依然会卡住 SQL 线程。
