MySQL复制不管用那个方式，都离不开binlog方式进行的。GTID作为position方式的延伸，在如今使用环境中带来了很多方便。下面一步一步的把gtid相关的知识点复习一下。

基础

先了解复制的基本原理： 1.MySQL复制方式： master用户写入数据，生成event记到binary log中. slave接收master上传来的binlog，然后按顺序应用，重现master上的操作。 传统的复制基于(file,pos)，当主从发生宕机，切换的时候有问题 slave保存的是原master上的(file,pos)，无法直接指向新master上的(file,pos)

2.日志记录上position方式和GTID方式区别。 直观图对比：

• 主从复制,默认是通过pos复制(postion)方式,将用户进行的每一项操作都进行编号(pos),每一个event都有一个起始编号,一个终止编号。GTID就是类似于pos的一个作用,全局通用并且日志文件里事件的GTID值是一致的. pos与GTID在日志里是一个标识符，在slave 里已不同的方式展现。

• GTID的生成受gtid_next控制。 在Master上，gtid_next是默认的AUTOMATIC,即GTID在每次事务提交时自动生成。它从当前已执行的GTID集合(即gtid_executed)中，找一个大于0的未使用的最小值作为下个事务GTID。同时将GTID写入到binlog(set gtid_next记录)，在实际的更新事务记录之前。 在Slave上，从binlog先读取到主库的GTID(即set gtid_next记录)，而后执行的事务采用该GTID。

3.GTID优势

• 更简单的实现failover，不像传统方式那样在需要找log_file和log_Pos。
• 更简单的搭建主从复制。
• 复制集群有一个统一的方式识别复制位置，给集群管理带来了便利。
• 正常情况下，GTID是连续没有空洞的，因此主从库出现数据冲突时，可以用添加空事物的方式进行跳过。
• MySQL5.7.6版本开始可以在线升级gtid模式

冷门功能：接口

这类接口MySQL初期是为了通过开发接口，解决执行状态和复制延迟的跟踪准备的。但现在基本不适用。

1.FUNCTION

• GTID_SUBSET(set1,set2) 给定两组全局事务标识符set1和set2，如果set1中的所有gtid也在set2中，则返回true。否则返回false。