首先确认 mysql 版本支持 GTID 并检查相关参数配置，确保 log_bin、log_slave_updates 开启及 GTID 一致性启用；接着通过修改 my.cnf 并在从库和主库依次重启后启用 GTID 模式；然后在从库执行 CHANGE MASTER TO MASTER_AUTO_POSITION= 1 以切换至 GTID 复制；最后验证 Using_Gtid、Auto_Position 状态及主从 GTID 集合一致性，确保数据同步正常。迁移中需处理 Errant 事务、函数不一致及数据差异问题，推荐使用 pt-table-checksum 校验数据，整体过程需逐步操作以保障服务稳定。
MySQL 从传统复制切换到 GTID 复制，或者在已有 GTID 环境中迁移复制拓扑，是 数据库 维护中常见的需求。GTID（Global Transaction Identifier）提供了更安全、更简单的主从切换和故障恢复机制。以下是实现 MySQL GTID 复制迁移的实用方法。
确认当前环境是否支持 GTID
在开始迁移前，确保你的 MySQL 版本支持 GTID（MySQL 5.6 及以上版本支持，推荐使用 5.7 或 8.0）。同时检查以下参数：
- gtid_mode：当前是否启用 GTID
- enforce_gtid_consistency：是否强制 GTID 一致性
- log_bin 和 log_slave_updates：必须开启
执行如下命令查看：
select @@gtid_mode, @@enforce_gtid_consistency, @@log_bin, @@log_slave_updates;
如果未开启，需先配置 my.cnf：
[mysqld]
gtid_mode = ON
enforce_gtid_consistency = ON
log_bin = mysql-bin
log_slave_updates = ON
binlog_format = ROW
逐步启用 GTID（在线迁移）
为避免服务中断，建议采用渐进式迁移方式：
- 在主库和所有从库上修改 my.cnf，添加上述 GTID 相关参数
- 依次重启从库，再重启主库（顺序不能错）
- 重启后，在每个节点执行：
SHOW VARIABLES LIKE ‘gtid_mode’;
确认都为 ON。
然后在从库上停止复制，切换到 GTID 模式：
STOP SLAVE;
CHANGE MASTER TO MASTER_HOST=’ 主库 IP’,
MASTER_AUTO_POSITION = 1;
START SLAVE;
MASTER_AUTO_POSITION = 1 是启用 GTID 复制的关键。
验证 GTID 复制状态
在从库上运行：
SHOW SLAVE STATUSG
关注以下字段：
- Using_Gtid：应显示 Slave_Pos 或 Current_Pos
- Auto_Position：应为 1
- Seconds_Behind_Master：确认复制延迟正常
也可查询：
SELECT @@global.gtid_executed;
对比主从的 GTID 集合，确保从库已追平主库。
处理 常见问题
迁移过程中可能遇到的问题及应对方法：
- Errant transactions：非 GTID 环境下的手动写入可能导致不一致。可通过注入空事务跳过：
SET session GTID_NEXT=’ 指定 GTID’;
BEGIN; COMMIT;
SET SESSION GTID_NEXT=’AUTOMATIC’;
- 函数或触发器导致不一致：确保所有语句符合 GTID 一致性要求，如避免在函数中使用非确定性操作
- 主从数据差异：迁移前建议使用 pt-table-checksum 校验数据一致性
基本上就这些。只要步骤清晰，提前准备配置，GTID 迁移过程可以平稳完成。关键是确保所有节点都正确配置并启用自动定位（auto_position），这样复制关系才能稳定运行。
