官方支持5.7→8.0主从复制但非开箱即用，因认证插件不兼容、系统表结构差异和ddl解析失败三类硬伤，需手动对齐配置并严格检查同步状态，推荐使用debezium等工具链替代原生复制。
为什么不能直接用主从复制做5.7→8.0增量同步
官方文档写“支持”，但实际运行中START SLAVE后大概率静默失败，不是延迟高，而是Seconds_Behind_Master始终为NULL。根本原因是：5.7主库binlog里不带caching_sha2_password握手信息，而8.0从库默认要求该插件；同时，5.7的mysql.user表结构缺失plugin字段元数据，导致权限变更事件被跳过或误解析。
必须改的三项配置才能让复制勉强跑起来
若坚持用原生复制，以下配置缺一不可，且顺序不能错：
- 在5.7主库
my.cnf的[mysqld]段加：default_authentication_plugin=mysql_native_password，然后重启服务——否则新建用户仍用caching_sha2_password，后续无法同步 - 在8.0从库
my.cnf中显式收紧sql_mode：sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION，务必删掉ONLY_FULL_GROUP_BY和已移除的NO_AUTO_CREATE_USER - 5.7导出初始快照时，必须禁用GTID：
mysqldump --all-databases --routines --triggers --single-transaction --set-gtid-purged=OFF > init.sql；8.0导入后立即执行RESET MASTER，否则GTID冲突会卡死复制
启动复制后必须人工确认的两个关键状态
SHOW SLAVE STATUS\G只看Seconds_Behind_Master是陷阱。真正要盯的是：
-
Slave_IO_Running: Yes且Slave_SQL_Running: Yes只是表面；重点看Seconds_Behind_Master是否为整数（如0），若为NULL，说明IO线程根本没连上，99%是认证插件不匹配 - 翻8.0从库错误日志，搜索
Could not execute Write_rows_v1 event on table mysql.user——出现即表明5.7的用户表结构被拒绝，此时必须手动删掉从库mysql库下所有非InnoDB表（如plugin、servers），再STOP SLAVE; START SLAVE;
比原生复制更稳的增量方案：用Debezium + Kafka中转
生产环境别硬扛原生复制的兼容性雷区。推荐链路：MySQL 5.7 → Debezium Connector → Kafka → MySQL 8.0 Sink Connector。好处是：
- Debezium能自动适配5.7→8.0的字段类型映射（如
password→authentication_string） - 通过Kafka缓冲，可随时暂停/重放/过滤DDL，避免
ALTER TABLE类语句直接冲击8.0 - Sink端可配置
transforms统一转换字符集（强制utf8mb4）、替换废弃函数（如把PASSWORD()替换成SHA2()）
真正的难点不在工具链搭建，而在DDL事件的拦截与重写——比如5.7里CREATE TABLE t1 (id INT) ENGINE=MyISAM到8.0必须转成ENGINE=InnoDB，漏一条就可能卡住整个pipeline。
