升级 MySQL 后 gtid_mode
无法启用：必须先清理 binlog
MySQL 升级（尤其是跨大版本，如 5.7 → 8.0）后直接开启
gtid_mode=ON会失败，报错类似：
ERROR 3787 (HY000): Cannot turn on GTID_MODE when binary logging is disabled or when gtid_mode = OFF and there are previous GTIDs in the binary log.根本原因是：旧 binlog 文件里含有非 GTID 格式事件，而 MySQL 8.0 要求开启 GTID 前必须确保所有 binlog 中不含 legacy event，且
previous_gtid_event为空。最稳妥做法是清空 binlog 并重置 GTID 状态。 执行
RESET MASTER—— 删除所有 binlog 文件并重置
mysql.gtid_executed表 确认
SHOW MASTER STATUS返回空结果、
SELECT * FROM mysql.gtid_executed返回空集 再设置
gtid_mode=ON和
enforce_gtid_consistency=ON，否则启动会拒绝 注意：
RESET MASTER不可逆，主从切换期间需停写或提前切流
enforce_gtid_consistency
的三个级别实际影响
该参数不是布尔开关，而是枚举值：
OFF、
WARN、
ON。升级后若只设
gtid_mode=ON但漏设
enforce_gtid_consistency=ON，MySQL 允许启动，但后续遇到不兼容语句（如
CREATE TEMPORARY TABLE、
INSERT ... SELECT涉及非事务表）会直接报错中断事务，而不是降级警告。
OFF：不检查，GTID 可能生成但不保证一致性（危险，禁用）
WARN：记录 warning 日志但允许执行（仅调试用）
ON：强制拦截不安全语句，确保所有事务可被 GTID 唯一标识 必须在
gtid_mode=ON之前或同时设为
ON，否则 MySQL 会拒绝启动
主从切换时 CHANGE REPLICATION SOURCE TO
的 GTID 参数写法
MySQL 8.0.23+ 已弃用
CHANGE MASTER TO，新语法必须用
CHANGE REPLICATION SOURCE TO，且开启 GTID 后不能再指定
MASTER_LOG_FILE和
MASTER_LOG_POS。错误写法会导致复制启动失败或跳过部分事务。 正确写法：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='10.0.1.2', SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_AUTO_POSITION=1;
SOURCE_AUTO_POSITION=1是关键，它让从库自动向主库请求缺失的 GTID 集合 若手动指定位置（哪怕值正确），MySQL 会忽略 GTID 自动定位逻辑，导致复制断裂 首次配置前，务必确认从库
SELECT @@GLOBAL.GTID_EXECUTED包含主库已执行的所有 GTID
升级后 mysql.gtid_executed
表数据异常的修复路径
某些升级场景（如 5.7 升 8.0 时未清 binlog）会导致
mysql.gtid_executed表残留脏数据，表现为
SHOW SLAVE STATUS\G中
Retrieved_Gtid_Set与
Executed_Gtid_Set不连续，或复制卡在某 GTID 上不动。 先停复制：
STOP REPLICA检查当前 GTID 执行状态：
SELECT * FROM mysql.gtid_executed，对比
SELECT @@GLOBAL.GTID_EXECUTED若表中存在孤立区间（如只有
aaa-bbb-ccc:1-100，但全局变量含
:101-200），需重建：
TRUNCATE TABLE mysql.gtid_executed; INSERT INTO mysql.gtid_executed SELECT * FROM performance_schema.replication_applier_status_by_worker;最后
START REPLICA，观察是否恢复追赶
GTID 不是“开了就稳”的功能，升级后 binlog 清理、参数顺序、复制语句写法、系统表一致性这四点，任一遗漏都会引发隐性故障。尤其
RESET MASTER和
SOURCE_AUTO_POSITION=1这两个动作，容易因文档混淆或习惯性写旧命令而跳过。
