GTID（Global Transaction Identifier，全局事务标识符）：MySQL 主从复制的核心机制

GTID（Global Transaction Identifier，全局事务标识符）是 MySQL 数据库在主从复制中引入的核心机制，用于唯一标识全局事务，简化复制管理和故障转移流程。其核心概念与工作机制如下：

---

一、GTID 的定义与组成

基本结构

GTID 由两部分构成：source_id:transaction_id。

• source_id：即 MySQL 实例的唯一标识 server_uuid（首次启动时生成，存储在 auto.cnf 文件中）。
• transaction_id：事务在实例上的顺序号，从 1 开始单调递增。

示例：3E11FA47-71CA-11E1-9E33-C80AA9429562:23。

全局唯一性

同一事务的 GTID 在整个复制拓扑中保持不变，即使经过多级主从（如 主库 → 从库 A → 从库 B）。

---

二、GTID 的核心工作原理

事务提交与 GTID 生成

主库提交事务时生成 GTID，并将其写入 Binlog 头部（通过 GTID_Event 事件）。

从库同步流程

1. I/O 线程：将主库的 Binlog 写入从库的 Relay Log。
2. SQL 线程：读取 Relay Log 中的 GTID，检查从库的 gtid_executed 集合：
   • 若 GTID 已存在 → 忽略 该事务（避免重复执行）。
   • 若 GTID 不存在 → 执行 事务并记录 GTID 到从库 Binlog。

自动定位复制点

从库通过 MASTER_AUTO_POSITION=1 向主库发送已执行的 GTID 集合，主库自动推送缺失的事务。

---

三、GTID vs 传统复制（Binlog Position-Based）

特性	传统复制	GTID 复制
故障切换	需手动定位 Binlog 文件和位置点	自动匹配 GTID，无需人工干预
数据一致性	可能重复执行事务（如位置点配置错误）	通过 GTID 唯一性避免重复执行
配置复杂度	需指定 MASTER_LOG_FILE 和 POS	仅需 MASTER_AUTO_POSITION=1
多级复制管理	复杂，需逐级传递位置点	自动跟踪事务路径，简化级联复制

---

四、使用限制与注意事项

操作限制

• 禁止非事务操作（如 MyISAM 表更新）。
• 不支持 CREATE TABLE ... SELECT、临时表操作（在 enforce_gtid_consistency=ON 模式下）。

配置要求

• 主从所有节点必须启用 GTID（gtid_mode=ON）。
• 从库需开启 Binlog（log-bin=ON）和 log-slave-updates（级联复制时）。

常见问题

• UUID 冲突：从库需删除 auto.cnf 以生成新 UUID。
• GTID 空洞：大事务可能导致复制延迟，需拆分事务。

---

五、运维实践

启用 GTID

在 my.cnf 添加：

gtid_mode=ON
enforce_gtid_consistency=ON
log-bin=mysql-bin

重启 MySQL 服务生效。

跳过错误事务

STOP SLAVE;
SET GTID_NEXT='aaa-bbb:100';  -- 指定需跳过的GTID
BEGIN; COMMIT;               -- 注入空事务
SET GTID_NEXT='AUTOMATIC';
START SLAVE;

监控状态

SHOW SLAVE STATUS\G;
-- 关键指标：
--   Slave_IO_Running: Yes
--   Slave_SQL_Running: Yes
--   Retrieved_Gtid_Set: 已接收的GTID
--   Executed_Gtid_Set: 已执行的GTID

---

总结

GTID 通过全局唯一事务标识和自动位置跟踪，显著提升了 MySQL 复制的可靠性与运维效率，尤其适用于大规模集群和故障切换场景。其核心价值在于：

• 简化主从配置：无需手动定位 Binlog 位置。
• 确保数据一致性：避免重复执行或遗漏事务。
• 加速故障恢复：主从切换时自动同步缺失事务。

---

注： 对 MySQL 5.7+ 环境，建议优先使用 GTID 复制；若需兼容旧版本或特殊操作，可评估传统复制方案。