GTID复制是MySQL 5.6版本引入的主从复制机制，全称为全局事务标识符复制，每个在主库执行的事务都会被分配一个全局唯一的GTID，从库通过GTID来识别需要同步的事务，不需要再依赖传统的binlog文件名和位置点。这种机制大幅简化了主从复制的配置和故障切换流程，是生产环境数据库集群常用的复制方案。
GTID复制的核心原理
GTID由两部分组成，格式为source_id:transaction_id，其中source_id是主库的UUID，transaction_id是事务的序列号，从1开始递增。主库执行事务时会生成对应的GTID，并记录到binlog中，从库的IO线程拉取binlog后，SQL线程会先检查该GTID是否已经在从库执行过，如果未执行则应用事务，已执行则跳过，避免事务重复执行。
GTID复制相关的核心参数如下：
- gtid_mode：控制GTID模式的开启状态，可选值为OFF、OFF_PERMISSIVE、ON_PERMISSIVE、ON，生产环境需要设置为ON
- enforce_gtid_consistency：保证所有事务都支持GTID，避免不支持GTID的事务执行，需要设置为ON
- log_bin：开启binlog日志，GTID复制依赖binlog传输
- log_slave_updates：从库开启该参数后，会将同步的事务记录到自身的binlog中，用于级联复制场景
GTID复制常见问题及处理方法
1. 主从复制中断，报错事务GTID已存在
这种问题通常是因为从库之前已经执行过该GTID对应的事务，或者主从切换后GTID集合出现冲突导致。首先可以查看从库复制状态，定位报错的具体GTID：
-- 查看从库复制状态，找到Last_SQL_Error中的GTID信息 SHOW SLAVE STATUSG
如果确认该事务在从库已经执行过，可以跳过这个GTID继续复制：
-- 停止从库复制线程 STOP SLAVE; -- 设置跳过该GTID SET GTID_NEXT='报错的GTID值'; -- 执行一个空事务 BEGIN;COMMIT; -- 恢复GTID自动分配 SET GTID_NEXT='AUTOMATIC'; -- 启动从库复制线程 START SLAVE;
2. 主从数据不一致，GTID同步正常但数据有差异
这种情况可能是主库执行了不支持GTID的事务，或者从库手动修改了数据导致。首先可以通过pt-table-checksum工具检查主从数据一致性，定位差异的表：
# 检查主从数据一致性，需要提前安装percona-toolkit pt-table-checksum --host=主库IP --user=检查用户 --password=密码 --databases=需要检查的数据库名
确认差异后，使用pt-table-sync工具修复数据：
# 修复主从数据差异，--execute表示执行修复操作 pt-table-sync --host=主库IP --user=修复用户 --password=密码 --databases=差异数据库名 --execute
3. 主库宕机后切换从库，GTID集合不连续
主库宕机后，新主库可能缺少部分已提交事务的GTID，导致其他从库同步时找不到对应的GTID。此时需要先查看新主库的GTID集合：
-- 查看新主库的GTID执行集合 SHOW GLOBAL VARIABLES LIKE 'gtid_executed';
如果是新主库确实缺少事务，需要找到旧主库未同步到新主库的binlog，手动补充缺失的GTID事务，或者重新搭建从库同步链路。如果是因为GTID集合中有空洞，可以开启gtid_purged参数跳过不需要的GTID：
-- 停止从库复制 STOP SLAVE; -- 设置需要跳过的GTID集合，多个GTID用逗号分隔 SET GLOBAL gtid_purged='缺失的GTID1,缺失的GTID2'; -- 重新配置从库同步 CHANGE MASTER TO MASTER_HOST='新主库IP',MASTER_USER='同步用户',MASTER_PASSWORD='密码',MASTER_AUTO_POSITION=1; -- 启动从库复制 START SLAVE;
GTID复制的注意事项
使用GTID复制时，不要在从库手动执行修改数据的操作，避免GTID集合混乱。主从切换前需要确保所有从库都同步完成主库的所有事务，避免数据丢失。定期备份主从库的binlog和GTID相关信息，出现故障时可以快速恢复。如果需要进行大版本升级或者迁移，建议先关闭GTID模式，完成操作后再重新开启，避免兼容性问题。