MySQL升级后主从复制中断主因是GTID模式不一致，需确保主从gtid_mode与enforce_gtid_consistency均为ON，且权限、binlog保留、启动顺序等全链路一致。
升级后主从复制中断：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 区间。升级过程常伴随重启、延迟加剧，加剧该问题。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
实操建议：
- 升级前务必检查主库
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，但也把一致性校验推到了每个环节：配置、权限、日志生命周期、启动顺序。漏掉任意一环，复制就会卡在你看不见的地方。
