5.7→8.0跨版本复制存在认证插件不兼容、gtid解析失败、系统表结构差异三类硬伤，需强制主库使用mysql_native_password、关闭gtid、导出时加--set-gtid-purged=off，并双向验证参数。
不能直接复用原有主从配置，5.7→8.0跨版本复制存在三类硬伤：认证插件不兼容、GTID解析失败、系统表结构差异，必须手动对齐参数并验证同步状态，否则START SLAVE后大概率静默中断。
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 线程
SHOW SLAVE STATUS\G 里 Seconds_Behind_Master 一直是 NULL 怎么办
这不是延迟高，而是 IO 线程根本没连上——通常因认证失败触发重连循环。必须人工确认两项：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 检查 8.0 从库错误日志，搜
Authentication plugin 'caching_sha2_password' reported error或Could not execute Write_rows_v1 event on table mysql.user，前者说明插件没对齐，后者说明系统表结构冲突 -
SHOW SLAVE STATUS\G中若Retrieved_Gtid_Set为空但Executed_Gtid_Set有值，说明 GTID 已错乱，必须删掉从库mysql库下所有非 InnoDB 表（如plugin、servers），再RESET SLAVE ALL重配
mysqldump 导出导入后复制启动失败的隐藏坑
全量迁移阶段最容易忽略的是 GTID 和初始化状态冲突：
- 5.7 主库导出时必须加
--set-gtid-purged=OFF，否则 dump 文件里会写死 GTID 信息，8.0 从库导入后无法对齐 - 8.0 从库导入完成后，立刻执行
RESET MASTER，清空自身gtid_purged，避免与主库 GTID 集合冲突 - 启动复制前，确认主库
binlog_format=ROW且gtid_mode=OFF（官方仅支持 5.7→8.0 在 GTID 关闭状态下运行）
真正麻烦的不是配置项本身，而是这些修改必须在主从两端严格同步生效——比如主库改了 default_authentication_plugin，但从库没同步更新 sql_mode 去掉 ONLY_FULL_GROUP_BY，遇到含分组查询的 binlog 依然会卡在 SQL 线程。每个参数变更都要双向验证，不能只调一头。
