MySQL 的 GTID 模式

**TID（Global Transaction ID，全局事务 ID）**是 MySQL 复制体系的一种机制，用来唯一标识每一个事务，从而让主从复制变得更可靠、更自动化、更不容易出错。

一句话总结：

GTID = 给每个事务一个全球唯一的身份证号，让复制自动、可追踪、可恢复。

GTID 的结构

GTID 的格式是：

source_id:transaction_id

例如：

3E11FA47-71CA-11E1-9E33-C80AA9429562:12345

• source_id ：通常是主库的 server_uuid

• transaction_id：从 1 开始递增的事务序号

GTID 模式解决了什么问题？

传统复制（基于 binlog 文件 + position）有几个痛点：

问题	传统复制	GTID
主从切换	需要手动找 binlog 文件和位置	自动定位，秒级切换
数据恢复	容易错位、跳点	自动跳过已执行事务
复制一致性	依赖人工操作	事务级别精确一致
故障恢复	麻烦	自动找位置、自动恢复

所以 GTID 的核心价值是：

让复制变得自动化、可恢复、可追踪，特别适合高可用架构（MGR、主从、ProxySQL）。

GTID 的工作原理（你会喜欢这个解释）

1. 主库执行一个事务 → 生成一个唯一 GTID

2. 主库把 GTID 写入 binlog

3. 从库拉取 binlog

4. 从库检查：

   • 如果这个 GTID 已经执行过 → 跳过

   • 如果没执行 → 执行并记录

5. 从库把已执行的 GTID 集合记录在 gtid_executed 中

这意味着：

从库永远不会重复执行事务，也不会漏执行事务。

GTID 模式常见配置（MySQL 8.0.36 环境）

在 my.cnf 中：

gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
binlog_format=ROW

你现在的 MGR 环境本身就依赖 GTID，所以你已经在使用它。

为什么 MGR 必须使用 GTID？

因为 MGR 是"事务级复制 + 共识协议"，它需要：

• 全局唯一事务 ID

• 精确的事务顺序

• 自动冲突检测

没有 GTID，MGR 根本无法工作。

你作为架构师应该记住的 GTID 核心价值

• 自动定位复制位置（不用再找 binlog 文件和 pos）

• 自动跳过重复事务

• 主从切换更快、更安全

• 故障恢复更简单

• MGR、半同步、ProxySQL 都依赖它

GTID 是现代 MySQL 高可用体系的基础。