汇总丨MySQL GTID技术点，看这一篇就够了！

墨墨导读：对于MySQL GTID，经过多年的磨炼已经很稳定了，作为position方式的延伸，在如今使用环境中带来了很多方便。本文分享GTID技术点的汇总。

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。
  

• GTID_SUBTRACT(set1,set2)
  给定两组全局事务标识符set1和set2，只返回set1中不属于set2的gtid。
  

• WAIT_FOR_EXECUTED_GTID_SET()
  监视应用于服务器上的所有gtid，包括从所有复制通道和用户客户机到达的事务。
  如果指定了超时，并且在GTID集中的所有事务应用之前超时时间已经过去，则函数停止等待。超时是可选的，默认超时为0秒，在这种情况下，函数总是等待，直到应用了GTID集中的所有事务。
  

• WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(gtid_set[, timeout][,channel])
  等待所有事务都已应用，或者等待超时时间过完。8.0.18弃用功能，暂不介绍。

参考：https://dev.mysql.com/doc/refman/5.7/en/gtid-functions.html

2. API

跟踪gtid从库接受的情况，返回值：成功的为零。发生错误时非零。
跟踪器机制的一种用途是为MySQL连接器和客户端应用程序提供一种方法，能确保执行情况 ，已经有增强半同步这样的机制，基本没有，除非进行二次开发

• mysql_session_track_get_first()