升级后主从复制中断：GTID mode 不一致导致 ERROR 1236
MySQL 升级（如 5.7 → 8.0）后常见主从复制中断，错误日志里出现
ERROR 1236 (HY000): Got fatal error 1236 from master when reading data from binary log，根本原因是主从两端
gtid_mode或
enforce_gtid_consistency配置不匹配。8.0 默认强制 GTID，而旧版本可能为
OFF或
ON_PERMISSIVE，升级后若未统一调整，IO 线程无法正确解析 binlog 事件。
实操建议：
升级前确认所有节点当前 GTID 状态：SELECT @@gtid_mode, @@enforce_gtid_consistency;主从必须保持完全一致：
gtid_mode = ON且
enforce_gtid_consistency = ON，否则
CHANGE MASTER TO会拒绝执行 若原主库是 5.6/5.7 且未开启 GTID，不能直接升级后启 GTID 并复制定向——必须先在旧版本上启用 GTID（需满足全部事务为 GTID-safe），再升级 升级后首次启动从库前，检查
mysql.gtid_executed表是否完整；若缺失或损坏，可能需手动补全
SET GLOBAL gtid_purged = '...';
CHANGE MASTER TO 报错 “This operation cannot be performed with a running slave”
升级后尝试重配复制时，执行
CHANGE MASTER TO报该错，说明 SQL 线程或 IO 线程仍在运行。8.0 对复制配置变更更严格，不允许热修改连接参数。
实操建议：
必须先停掉复制：STOP SLAVE;确认已停止：
SHOW SLAVE STATUS\G中
Slave_IO_Running和
Slave_SQL_Running均为
No若
STOP SLAVE卡住（如 SQL 线程正处理大事务），可加
IO_THREAD或
SQL_THREAD限定停指定线程 改完配置后，用
START SLAVE启动，不要漏掉
START SLAVE IO_THREAD单独启 IO（某些场景下 SQL 线程依赖 IO 先拉取）
主库升级后从库报 “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”
这是典型的 GTID 同步断裂：主库 binlog 被清理（
expire_logs_days或
PURGE BINARY LOGS），而从库还没来得及拉取对应 GTID 区间。升级过程常伴随重启、延迟加剧，加剧该问题。
实操建议：
升级前务必检查主库SELECT @@global.gtid_purged;和从库
SELECT Retrieved_Gtid_Set, Executed_Gtid_Set FROM performance_schema.replication_connection_status;是否有交集 若已断裂，不能靠
START SLAVE自动恢复，必须人工干预：要么用备份+
mysqldump --set-gtid-purged=ON重建从库，要么主库导出缺失 binlog 并在从库
mysqlbinlog | mysql补齐 升级窗口内禁止
PURGE BINARY LOGS；临时调大
binlog_expire_logs_seconds（8.0+）或
expire_logs_days（5.7） 从库升级后首次启动，建议加
--skip-slave-start参数，确认
gtid_executed正确后再手动
START SLAVE
MySQL 8.0 复制用户权限变更引发的连接失败
8.0 移除了
REPLICATION SLAVE以外的旧权限别名，且要求复制用户必须拥有
BACKUP_ADMIN（用于读取加密表空间元数据）和
REPLICATION_APPLIER（用于 GTID 事务应用）。仅保留
REPLICATION SLAVE会导致 IO 线程连上但无法注册 GTID。
实操建议：
检查复制用户权限：SHOW GRANTS FOR 'repl'@'%';补全必要权限：
GRANT REPLICATION SLAVE, REPLICATION APPLIER, BACKUP_ADMIN ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES;注意：8.0.22+ 还要求
SYSTEM_VARIABLES_ADMIN（若主库启用了
binlog_transaction_compression等新特性） 避免使用
root或高权限账号做复制用户——权限最小化原则在 GTID 场景下更关键，否则
START SLAVE可能静默失败
GTID 同步不是开关一开就稳的机制，它把“位置”从文件名+偏移量变成了全局唯一事务 ID，但也把一致性校验推到了每个环节：配置、权限、日志生命周期、启动顺序。漏掉任意一环，复制就会卡在你看不见的地方。
