mysql 5.7 gtid复制不能直接平滑切换到8.0，因系统表结构、认证插件、sql模式等底层不一致会导致中断；可行路径是保留gtid模式，停主库写入后做最小窗口滚动切换。
MySQL 5.7 的 GTID 复制不能直接“平滑切换”到 8.0——GTID 本身是兼容的，但复制链路会因系统表结构变更、认证插件升级、SQL 模式收紧等底层不一致而中断。真正可行的路径是：保留 GTID 模式，停主库写入后做一次最小窗口的主从滚动切换，而非在线热切。
为什么 mysqldump + GTID 导入在 8.0 上必然失败
你试图用 mysqldump --set-gtid-purged=ON 导出再导入到 8.0 实例，结果复制报错 ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires，根本原因不是日志被删，而是：
- 5.7 的
mysql.gtid_executed表结构（含source_uuid,interval_start,interval_end）与 8.0 的mysql.gtid_executed（已合并进mysql.binlog_index和数据字典）不兼容，导入会静默跳过或写入脏数据 -
mysqldump不导出mysql.slave_master_info和mysql.slave_relay_log_info的 GTID 位点状态，新从库启动后无法对齐Retrieved_Gtid_Set和Executed_Gtid_Set - 若原 5.7 实例启用了
enforce_gtid_consistency=OFF或存在非 GTID 安全语句（如CREATE TEMPORARY TABLE），dump 文件里会混入无 GTID 的 binlog event，8.0 从库拒绝执行
必须用 mysql-shell 的 util.checkForServerUpgrade 扫描 GTID 兼容性
GTID 切换前最常被忽略的一环：检查是否所有 GTID 相关对象都满足 8.0 要求。仅靠 SHOW MASTER STATUS 或 SELECT * FROM mysql.gtid_executed 看不出问题。
- 下载与目标 8.0 版本严格一致的
mysql-shell（如升到 8.0.42，就用mysql-shell-8.0.42） - 确保 5.7 主库正在运行，且 root 可通过 socket 连接：
mysqlsh -uroot -p -S /tmp/mysql.sock -e "util.checkForServerUpgrade({targetVersion: '8.0.42'})" - 重点看报告中以下 ERROR 级别项：
-
GTID mode is enabled but enforce_gtid_consistency is OFF→ 必须先在 5.7 主库设SET GLOBAL enforce_gtid_consistency = ON，再重启从库并确认无错误 -
Non-transactional tables used with GTID replication→ MyISAM 表不支持 GTID，需转为 InnoDB 或剔除 -
Binary log format is not ROW→ GTID 要求binlog_format=ROW，否则 8.0 从库无法解析
-
主从滚动切换时如何保持 GTID 连续性
不能停主库太久，也不能让 GTID gap 出现。核心是让新 8.0 从库从旧 5.7 主库的最新 Executed_Gtid_Set 接续，而不是重放全部 binlog。
- 在 5.7 主库上执行：
SELECT @@GLOBAL.gtid_executed;，记下完整 GTID 集合（如aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:1-100） - 将 8.0 实例配置为从库前，先手动设置其
gtid_purged：SET GLOBAL gtid_purged = 'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:1-100'; - 再执行
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION = 1;—— 此时 8.0 从库会自动跳过已 purge 的事务，只拉取新日志 - 验证：
SHOW SLAVE STATUS\G中Retrieved_Gtid_Set应大于Executed_Gtid_Set，且Seconds_Behind_Master = 0
Windows 下滚动切换最容易卡在服务注册和权限继承
在 Windows 上做完二进制替换、配置好 my.ini 后，START SLAVE 报错 ERROR 2003 (HY000): Can't connect to MySQL server on 'xxx'，大概率不是网络问题：
- 确认旧服务已彻底卸载：
sc delete MySQL，否则mysqld --install仍注册为旧路径下的 5.7 服务 - 新
my.ini中必须显式包含：default_authentication_plugin=mysql_native_password，否则 5.7 的复制用户（用mysql_native_password插件创建）无法连接 8.0 主库 -
datadir目录权限必须继承自 LocalSystem 或你指定的服务账户，否则 8.0 mysqld 无法读取mysql.gtid_executed的元数据文件，导致 GTID 初始化失败 - 不要依赖宝塔或一键脚本自动处理 GTID 切换——它们通常忽略
gtid_purged手动注入这一步，导致从库始终卡在Waiting for master to send event
GTID 平滑切换真正的复杂点不在命令本身，而在于你能否准确识别出那个“最后一条已执行事务”的 GTID，并把它干净地注入到新实例中；漏掉一个字符、多一个空格、或者没清空旧服务注册表，都会让复制永远停在 Retrieved_Gtid_Set 和 Executed_Gtid_Set 不对齐的状态。
