GTID（global transaction identifier）全局事务ID是MySQL５.6引入的新特性，它会为每个事务分配一个唯一的事务ID。事务ID的格式如下：
source_id:transaction_id
它由两部分组成，其中：
source_id表示事务是在哪个实例上产生的，通常用实例的server_uuid来表示。
transaction是事务的序列号，按照事务提交的顺序从1开始顺序分配。
这样，可保证GTID在整个复制拓扑中都是全局唯一的。
传统的复制是基于binlog位置点的。在搭建的时候，需指定master_log_file和master_log_pos。这个位置的准确性十分关键，如果弄错了，很容易导致主从数据不一致，甚至主从复制中断。
在一主多从的架构中，在主库出现故障，将一个从库提升为主库后，剩下的从库并不知道要基于哪个位置点与新主库建立复制关系。毕竟，主库上的同一个操作，在不同从库上对应的binlog位置点基本上都不相同。这也是MHA（MySQL高可用管理工具）出现的背景，它能自动计算出搭建复制时要指定的位置点。但在更加复杂的复制拓扑（如级联复制）中，即使MHA也无能为力。
引入GTID的初衷其实就是为了简化复制的日常管理。有了GTID，无论是搭建复制、拓扑变更，还是高可用切换都无须再关心具体的binlog位置点信息。
另外一个流行的MySQL高可用管理工具Orchestrator支持复杂的、基于binlog位置点的复制拓扑的管理。在实现上，它会定期（默认每5秒）向主库注入一个Pseudo-GTID事务，该事务只有一个简单的删除视图（DROP VIEW）操作。比如：
drop view if exists '_pseudo_gtid_'.'_asc:5dcfce93:00000001:96b185b1e799c12e'
视图名其实就是一个很好的GTID。
