对于MySQLGTID来说，经过多年的磨炼已经很稳定了，相关的知识点网上也很多，本次分享GTID技术点的汇总。
MySQL复制不管用那个方式，都离不开binlog方式进行的。GTID作为position方式的延伸，在如今使用环境中带来了很多方便。下面一步一步的把gtid相关的知识点复习一下。
基础
先了解复制的基本原理：
1.MySQL复制方式：
master用户写入数据，生成event记到binarylog中.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(setgtid_next记录)，在实际的更新事务记录之前。在Slave上，从binlog先读取到主库的GTID(即setgtid_next记录)，而后执行的事务采用该GTID。
3.GTID优势
更简单的实现failover，不像传统方式那样在需要找logfile和logPos。更简单的搭建主从复制。复制集群有一个统一的方式识别复制位置，给集群管理带来了便利。正常情况下，GTID是连续没有空洞的，因此主从库出现数据冲突时，可以用添加空事物的方式进行跳过。MySQL5.7.6版本开始可以在线升级gtid模式冷门功能：接口
这类接口MySQL初期是为了通过开发接口，解决执行状态和复制延迟的跟踪准备的。但现在基本不适用。
1.FUNCTION
GTID_SUBSET(set1,set2)给定两组全局事务标识符set1和set2，如果set1中的所有gtid也在set2中，则返回true。否则返回false。
GTID_SUBTRACT(set1,set2)给定两组全局事务标识符set1和set2，只返回set1中不属于set2的gtid。
WAITFOREXECUTEDGTIDSET()监视应用于服务器上的所有gtid，包括从所有复制通道和用户客户机到达的事务。如果指定了超时，并且在GTID集中的所有事务应用之前超时时间已经过去，则函数停止等待。超时是可选的，默认超时为0秒，在这种情况下，函数总是等待，直到应用了GTID集中的所有事务。
WAITUNTILSQLTHREADAFTERGTIDS(gtidset[,timeout][,channel])等待所有事务都已应用，或者等待超时时间过完。8.0.18弃用功能，暂不介绍。参考：