MySQL升级后复制失败的五大典型问题及修复：①IO线程卡Connecting因主库用caching_sha2_password，需改用mysql_native_password；②GTID冲突报错需SET GLOBAL gtid_purged修正；③server_uuid重复须删auto.cnf重建；④DDL执行失败可调slave_ddl_exec_mode临时缓解；⑤须逐层校验配置、权限、协议、GTID、UUID。
MySQL升级后IO线程卡在Connecting状态
升级后Slave_IO_Running显示Connecting，Last_IO_Error为空或只报超时，大概率是主库拒绝新协议握手。MySQL 8.0+ 默认启用caching_sha2_password插件，而旧版从库（如5.7）不支持该认证方式。
检查主库复制账号的plugin字段：
SELECT user, host, plugin FROM mysql.user WHERE user = 'repl';
若返回caching_sha2_password，需立即修复：
- 在主库执行：
ALTER USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; FLUSH PRIVILEGES; - 确保从库
my.cnf中未强制设置default_authentication_plugin（尤其避免设为caching_sha2_password） - 重启从库MySQL服务（仅改用户权限无需重启，但部分旧客户端缓存需重连）
SQL线程启动失败报错“GTID_PURGED contains transactions not present in GTID_EXECUTED”
这是升级到8.0后最典型的GTID冲突，源于升级前未清空gtid_purged或主库binlog被清理过。错误信息里会明确出现GTID_PURGED和GTID_EXECUTED两个集合不匹配。
不要直接RESET MASTER——这会清空所有binlog并重置GTID，导致主从彻底失联。正确做法是让从库“承认”已丢失的部分：
- 在从库执行：
SELECT @@GLOBAL.gtid_purged;记下输出值（如'a1b2c3d4-1234-5678-90ab-cdef12345678:1-100'） - 对比主库
SHOW MASTER STATUS中的Executed_Gtid_Set，确认缺失范围 - 在从库执行：
SET GLOBAL gtid_purged = 'a1b2c3d4-1234-5678-90ab-cdef12345678:1-100';（必须在RESET SLAVE之后、START SLAVE之前） - 注意：
gtid_purged只能设为比当前gtid_executed更小的集合，且不能包含未执行过的GTID
升级后复制中断但错误日志无明显报错
某些情况下Last_IO_Error和Last_SQL_Error为空，Seconds_Behind_Master为NULL，但两个线程都停了。这往往是因为升级后server_uuid被重写，而从库仍持有旧auto.cnf——尤其常见于Docker容器或克隆部署场景。
验证方式：
- 主库执行：
SELECT @@server_uuid; - 从库执行：
SELECT @@server_uuid; - 若两者完全一致，复制必然失败，错误日志里会有
The replica I/O thread stops because source and replica have equal MySQL server UUIDs
修复步骤（必须停库）：
- 停从库：
docker stop mysql-slave或systemctl stop mysqld - 进入数据目录（如
/var/lib/mysql/），删除auto.cnf文件 - 启动从库，MySQL会自动生成新UUID
- 再执行
START SLAVE;，观察Slave_IO_Running是否变为Yes
升级后表结构变更语句执行失败
MySQL 8.0对DDL原子性和锁行为做了增强，某些在5.7能执行的ALTER TABLE（如加列、改默认值）在8.0可能触发SQL_THREAD中断，错误码常为HY000或ER_ALTER_OPERATION_NOT_SUPPORTED。
这不是数据不一致问题，而是语法兼容性问题。关键判断点：
- 查
Last_SQL_Error是否含ALTER、ALGORITHM=INPLACE等关键词 - 确认主库执行该DDL时是否加了
ALGORITHM=COPY或LOCK=SHARED等显式选项 - 从库
slave_ddl_exec_mode变量默认为STRICT，遇到不兼容DDL直接报错；可临时设为IDEAL（仅调试用）：SET GLOBAL slave_ddl_exec_mode = 'IDEAL';
真正根治方式是：主库执行DDL前，先在从库测试相同语句；生产环境避免使用ALGORITHM=INSTANT以外的隐式算法，因其在不同版本间行为差异大。
升级不是一次性的操作，而是配置、权限、协议、GTID、UUID五层校验的叠加过程。任何一个环节没对齐，复制就会静默失效——它不会总给你明显的错误提示，有时只停在那里，等你主动去SHOW SLAVE STATUS\G看一眼。
