在MySQL高可用架构中，主从复制是最基础的数据同步手段。早期基于位点（file+position）的复制方式要求从库明确知道主库binlog文件和偏移量，一旦主库发生切换或binlog被清理，从库就很容易因为位点不匹配而同步失败。基于GTID（Global Transaction Identifier，全局事务ID）的复制机制给每个事务分配一个全局唯一编号，从库通过记录已执行的事务集合来实现自动寻点，大幅降低了运维复杂度。
一、GTID的基本原理与结构
GTID由两部分组成：server_uuid和事务序号，格式为 uuid:transaction_id。其中server_uuid是MySQL实例启动时自动生成的唯一标识，transaction_id则是该实例上提交的事务的顺序编号。例如 3e11fa47-71ca-11e1-9e33-c80aa9429562:23 表示某个实例上的第23个事务。这种方式让每一个事务在整个人群集中都有唯一坐标，不会因binlog文件名变化而失效。
主库在提交事务时，会把GTID写入binlog；从库的IO线程拉取binlog后，SQL线程在重放前会检查该GTID是否已在自己的已执行集合中。如果已存在则跳过，避免重复执行。从库通过 gtid_executed 系统变量记录已经应用的事务，通过 gtid_purged 记录已从binlog清除但已执行的事务，这两者在故障恢复和级联复制中起到关键作用。
二、配置基于GTID的主从复制步骤
1. 主库与从库的基础参数设置
要让MySQL使用GTID模式，必须在主从双方同时开启相关参数并重启实例（GTID模式为只读启动参数）。核心参数包括 gtid_mode=ON、enforce_gtid_consistency=ON，后者会禁止那些无法以GTID安全执行的操作，比如CREATE TABLE ... SELECT 以及事务内混合非事务与事务引擎的写操作。同时建议开启 binlog 并设定 server-id 保证各节点唯一。
下面是一个典型的主库配置文件片段（my.cnf）：
[mysqld] server-id=1 log-bin=mysql-bin binlog_format=row gtid_mode=ON enforce_gtid_consistency=ON # 以下参数确保崩溃后binlog有序 sync_binlog=1 innodb_flush_log_at_trx_commit=1
从库配置只需修改 server-id 并保证同样开启GTID：
[mysqld] server-id=2 relay-log=relay-bin gtid_mode=ON enforce_gtid_consistency=ON read_only=ON
2. 建立复制通道并使用自动寻点
与传统复制不同，基于GTID的复制在 CHANGE MASTER 时不需要指定 MASTER_LOG_FILE 和 MASTER_LOG_POS。从库只要指向主库地址并开启 MASTER_AUTO_POSITION=1，MySQL就会利用GTID集合自动计算从库缺失的事务并从主库获取。这便是“自动寻点”的优势：无需人工查看 show master status 去对齐位点。
在从库执行如下语句建立复制：
CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='repl', MASTER_PASSWORD='repl_pass', MASTER_PORT=3306, MASTER_AUTO_POSITION=1; START SLAVE; -- 查看复制状态，重点看 Retrieved_Gtid_Set 与 Executed_Gtid_Set SHOW SLAVE STATUSG
如果配置正确，Slave_IO_Running 与 Slave_SQL_Running 均为 Yes，且 Executed_Gtid_Set 会随事务重放不断增长。当主库写入新数据时，从库能立即通过GTID定位并拉取对应事务，不会出现旧模式中因位点填写错误而报 Could not find first log file 的问题。
三、全局事务ID与自动寻点的实际优势
1. 故障切换更平滑
在MHA或Orchestrator等高可用工具场景下，旧位点模式需要在切换后重新计算新主库与从库的位点差，极易因中继日志残留导致数据断层。GTID模式下，从库只需比较自身的 gtid_executed 与新主库的 gtid_executed，自动补齐未执行部分。即便新主库并非原主库，只要事务ID不冲突，集群就能迅速恢复同步。
我们可以用一个简单对比表来看差异：
| 维度 | 基于位点复制 | 基于GTID复制 |
|---|---|---|
| 断点续传依据 | binlog文件+偏移量 | 全局事务ID集合 |
| 主库切换后操作 | 人工计算位点或工具解析 | 自动寻点，无需指定文件位点 |
| 重复执行风险 | 位点误填可能重放或跳过 | 已执行GTID自动跳过 |
2. 避免常见运维误区
不少团队在开启GTID后仍习惯性使用带位点的 CHANGE MASTER 语句，这会导致 MASTER_AUTO_POSITION 失效并退化为混合模式，反而引发报错。正确做法是只要 gtid_mode 开启，就统一使用自动寻点。另外，enforce_gtid_consistency 开启后，业务侧不能再用 CREATE TEMPORARY TABLE inside 事务，这类写法会被拒绝，需要改为会话级临时表或调整业务逻辑。
还有一点容易被忽略：当使用 mysqldump 搭建从库时，应加上 --set-gtid-purged=ON 参数，这样导出的备份文件会包含 GTID 信息，从库导入后 gtid_purged 被正确设置，避免从库试图重新拉取主库已清除的早期事务而造成复制错误。
四、常见问题排查与代码示例
1. 复制报错与跳过事务
如果因网络抖动出现事务冲突，可先暂停SQL线程并查看具体GTID。在GTID模式下，不建议使用传统的 sql_slave_skip_counter，而应通过注入空事务的方式跳过指定GTID：
STOP SLAVE SQL_THREAD; -- 假设需要跳过 3e11fa47-71ca-11e1-9e33-c80aa9429562:100 SET GTID_NEXT='3e11fa47-71ca-11e1-9e33-c80aa9429562:100'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE SQL_THREAD;
这种方式比位点跳过更安全，因为它精确针对某个事务ID，不会影响后续事务顺序。同时，主从数据一致性校验可借助 pt-table-checksum 等工具，在GTID环境下能够更准确识别差异来源。
2. 验证GTID同步状态
日常巡检时，可以通过如下语句观察主从GTID是否齐平：
-- 主库 SELECT @@global.gtid_executed; -- 从库 SELECT @@global.gtid_executed AS slave_executed, @@global.gtid_purged AS slave_purged;
若从库 gtid_executed 落后于主库，但 Slave 线程正常，一般是网络延迟或大体事务重放较慢，可通过并行复制参数 slave_parallel_workers 提升重放效率。GTID机制本身不限制并行度，配合多工作线程能显著缩短追平时间。
五、总结与实践建议
采用GTID主从复制的核心价值在于用全局事务ID替代易变的binlog位点，让自动寻点成为默认行为。部署时务必主从同时开启 gtid_mode 与 enforce_gtid_consistency，使用 MASTER_AUTO_POSITION=1 建立通道，并规范备份工具参数。对于新搭建的MySQL集群，GTID几乎是必选项，它在故障切换、数据修复和水平扩容方面都明显优于传统复制模式。
在真实业务中，建议结合监控平台采集 gtid_executed 延迟指标，一旦从库落后过多及时告警。只要理解GTID的集合运算逻辑与自动寻点原理，运维人员就能摆脱手动算位点的负担，把精力放在查询优化与架构设计上。