GTID(全局事务标识符)的深入解析
GTID(全局事务标识符)的深入解析
GTID(Global Transaction Identifier)是 MySQL 5.6 版本引入的一项核心功能,旨在解决传统主从复制中的痛点。它通过为每个事务赋予一个全局唯一的标识符,彻底改变了复制的管理方式。
一、传统复制的痛点
在 GTID 出现之前,MySQL 主从复制依赖 binlog 文件名 + 位置(如 mysql-bin.000003:107)来定位同步点,存在以下问题:
-  人工维护成本高 
 主库宕机切换时,需手动检查从库的 binlog 位置并重新配置同步起点,极易出错。
-  数据不一致风险 
 从库因网络中断跳过事务后,重新连接时可能因 binlog 轮换导致数据丢失或重复。
-  复杂拓扑管理困难 
 在链式复制(A→B→C)或多源复制场景中,维护多个 binlog 位置的映射关系几乎不可行。
二、GTID 的核心原理
GTID 的格式为:
 <source_id>:<transaction_id>
- source_id:数据库服务器的唯一标识(即- server_uuid,自动生成)
- transaction_id:事务在源服务器上的递增序号(从 1 开始)
示例:
 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5 表示某台服务器上提交的第 1 到第 5 个事务。
三、GTID 如何解决传统问题
1. 自动故障恢复(主从切换)
-  传统方式 
 需手动比对从库的 binlog 位置选择新主库,选错位置可能导致数据不一致。
-  GTID 方式 
 从库记录已执行的 GTID 集合(如3E11FA47...:1-5),新主库只需确保其 GTID 集合包含所有从库的 GTID 即可自动定位同步起点。
 简化操作:CHANGE MASTER TO MASTER_HOST=
