GTID
在线开启步骤：
1、要求：
（1）必须是5.7.6版本以上的mysql
（2）GTID状态为OFF
2、开启步骤：
（1）：SET GLOBAL ENFORCE_GTID_CONSISTENCY = ‘WARN’;
（2）：SET GLOBAL ENFORCE_GTID_CONSISTENCY = ‘ON’;
（3）：SET GLOBAL GTID_MODE = ‘OFF_PERMISSIVE’;
（4）：SET GLOBAL GTID_MODE = ‘ON_PERMISSIVE’;
（5）：SET GLOBAL GTID_MODE = ‘ON’;
3、要永久启用，在my.cnf配置文件中添加参数：
gtid-mode=ON
enforce-gtid-consistency
在线关闭步骤：
1、要求：
（1）必须是5.7.6版本以上的mysql
（2）GTID状态为OFF
2、关闭步骤：
（1）：stop slave;
（2）：SET GLOBAL GTID_MODE = ‘ON_PERMISSIVE’;
（3）：SET GLOBAL GTID_MODE = ‘OFF_PERMISSIVE’;
（4）：SET GLOBAL GTID_MODE = ‘OFF’;
注：
每次开启和关闭时，都是这样一个过程：
打开–>过度模式–>完全打开
停止–>过度模式–>完全关闭
开启GTID，需要在my.cnf指定以下参数，或在启动实例时命令行指定：
gtid-mode=on
enforce-gtid-consistency=1
log-slave-updates=1
log-bin=
在5.6版本开启GTID时必须开启log-slave-updates，因为GTID相关信息是存放在内存的，重启以后就丢失了，必须要从binlog里找到最新应用到的GTID；
在5.7版本由于引入了mysql.gtid_executed表，GTID信息存放在这个数据表里，那么重启之后就不再需要去读取binlog来获取GTID相关信息了。同时通过gtid_executed_compression_period参数控制执行了多少个事务以后，对mysql.gtid_executed表进行压缩，以免大量的GTID信息占用过多存储空间。
开启GTID后有如下限制：
1.不允许在同一个事务内对事务表和非事务进行DML操作，例如在同一个事务内先update innodb表，然后update myisam表。因为GTID强制每一个GTID对应一个事务，而在同一个事务内既操作innodb表又操作myisam，就会产生两个GTID；
2.不允许CREATE TABLE … SELECT语句，首先这种语句对于statement格式的binlog是不安全的；而对于row格式的binlog，这种语句在binlog实际是分成两个event进行记录的，一个记录create创建操作，一个记录insert操作，那么就有可能这两个操作是对应到同一个GTID上，而当将这两个拥有相同GTID的event传到从库时，从库就会忽略拥有相同GTID的insert操作，造成数据丢失；
3.CREATE TEMPORARY TABLE和DROP TEMPORARY TABLE不允许在事务内执行，只有在事务以外并且autocommit=1才能正常执行；
4.不支持sql_slave_skip_counter，如果需要跳过事务，可以用以下方法：
set @@session.gtid_next=’需要跳过的事务gtid’
begin;commit;
set session gtid_next=automatic;
当前场景
当前某些业务还有未开启GTID服务组，升级5.7后，如何检测是否符合开启GTID条件，如何在线修改切换使用GTID；已经升级5.7后，已经开启GTID，如何快速回滚后退；
线上gtid如何维护等等，以上场景通过归纳下面内容解决
gtid_mode参数新选项值
online gtid enable
online gtid disable
gtid_mode参数新选项
mysql 5.7.6后，mysql提供了两个额外选项off_permissive和on_permissive
off
off_permissive
on_permissive
on
上面四个状态变更必须是按照顺序变更，如不允许gtid_mode=off，直接变更为on_permissive;
当设置为off_permissive,不产生GTID事务, Slave接受不带GTID的事务(匿名事务)也接受带GTID的事务
当设置为on_permissive时，新事务为gtid事务，slave接受GTID事务也接受不带GTID事务
gtid值master 与slave 兼容性列表
上表说明
Y： 表示master和slave的gtid值是兼容的
N：表示master和slave的gtid值是不兼容的
Y：表示auto_positioning是可用的
online gtid enable
限制条件： mysql 版本需5.7.6之后；所有server gtid_mode=off
1 、在每一台服务器上执行。err log没有任何warning产生 ，这是非常重要的一步，确保没有error log产生继续step 2；主要验证是否可以开启gtid，如create table select from table 不支持事件
set @@global.enforce_gtid_consistency=warn;
2、在每一台server上执行
set @@global.enforce_gtid_consistency=on;
3、每一台server 执行，在那一台服务器执行没有先后之分
set @@global.gtid_mode=off_permissive;
4、每一台server 执行,执行顺序没有先后之分，要保证下一步操作之前，上面的操作都已在所有server上执行过
set @@global.gtid_mode=on_permissive;
5、保证每一台ongoing_anonymous_transaction_count状态值为零
show status like ‘ongoing_anonymous_transaction_count’;
6、等待步骤5生成的所有事务复制到所有服务器，此时不需要停止服务器更新，要保证所有的匿名事务都已经复制
7、步骤六完成，基本上可以进行步骤8.（此处没有考虑备份和restore情况）
8、设置 gtid_mode=on
set @@global.gtid_mode=on;
9、持久化my.cnf ，每台slave上执行
stop slave;
change master to master_auto_position=1 ;
start slave;
online gtid disable
限制：所有server必须5.7.6之后；gtid_mode=on
1、每一台slave上执行
stop slave;
change master to master_auto_position=0,master_log_file=’mysql-bin.000383’,master_log_pos= 245710922 ;
start slave;
2、在每一台server上执行
set @@global.gtid_mode=on_permissive;
3、在每一台server上执行 保证下一步操作之前，上面的操作都已在所有server上执行过
set @@global.gtid_mode=off_permissive;
4、在每一台server上执行，保证global.gtid_owned变量字符串为空。
select @@global.gtid_owned;
5、等待存在于binlog 中的事物都已经apply到slave
6、没有略过，在此过程中需关注是否有备份或restore
7、每一台server执行
set @@global.gtid_mode=off ;
8、持久化gtid_mode=off 到my.cnf配置文件
一 前言
MySQL DBA大都熟悉 MySQL 5.6版本开始提供基于 GTID 模式的主从复制，该特性简化复制和降低主从复制维护的难度，提高复制的可运维性，不再依赖binlog文件名和文件中的位置。 但是它有很多限制，5.7版本MySQL支持对GTID做了如下改进:
a 不需要重启MySQL服务器.
b 配置过程在线，整个复制集群仍然对外提供读和写的服务.
c 不需要改变复制拓扑结构.
d 可以在任何结构的复制集群中在线启用GTID功能.
在线修改GTID时，必须按照如下顺序
OFF <-> OFF_PERMISSIVE <-> ON_PERMISSIVE <-> ON
不能跳过其中环节，比如gtid_mode 从off 不能直接变为on，否则MySQL会进行提示。
ERROR 1788 (HY000): The value of @@GLOBAL.GTID_MODE can only be changed one step at a time: OFF <-> OFF_PERMISSIVE <-> ON_PERMISSIVE <-> ON. Also note that this value must be stepped up or down simultaneously on all servers. See the Manual for instructions.
在实践online升级之前，我们需要了解MySQL 5.7版本的GTID_MODE 的含义:
OFF :不产生GTID,Slave只接受不带GTID的事务
OFF_PERMISSIVE :不产生GTID,Slave即接受不带GTID的事务,也接受带GTID的事务
ON_PERMISSIVE :产生GTID,Slave即接受不带GTID的事务,也接受带GTID的事务
ON :产生GTID,Slave只能接受带GTID的事务。
二 在线开启GTID
需要说明的是只有数据库版本是 5.7.6以及之后 的版本才能支持在线开启GTID. 在测试开启GTID的同时模拟主库的读写压测：
sysbench –test=oltp.lua –oltp-tables-count=1 –oltp-table-size=500000 –mysql-db=sysbench –mysql-user=sysbench –mysql-password=sysbench –mysql-socket=/srv/my3316/run/mysql.sock –max-time=600 –num-threads=1 –oltp-test-mode=complex run
2.1 在主从复制结构中所有的实例中执行
set global ENFORCE_GTID_CONSISTENCY = WARN;
在正常运行的业务系统数据库中，设置ENFORCE GTID CONSISTENCY为WARN，目的是观察err log是否有不满足要求的sql出现。如果有发现任何warning，需要通知应用进行调整相关sql，直到不出现warning为止。GTID 使用限制如下:
1.不支持非事务引擎。
2.不支持create table … select 语句(在主库执行时直接报错)。
3.不允许一个SQL同时更新一个事务引擎和非事务引擎的表。
4.不支持create temporary table和drop temporary语句。
如果没有任何warning 出现，则在所有实例上执行:
set global ENFORCE_GTID_CONSISTENCY = ON;
2.2 在主从复制结构中所有实例中执行:
set global GTID_MODE = OFF_PERMISSIVE;
让主库不产生GTID,Slave实例即接受不带GTID的事务,也接受带GTID的事务。确保一定要在所有实例中执行完该命令之后再执行接下来的步骤。
2.3 在主从复制结构中所有实例中执行:
set global GTID_MODE = ON_PERMISSIVE;
主库开始产生GTID,Slave即接受不带GTID的事务,也接受带GTID的事务。
2.4 在主从复制结构中所有的实例中执行:
在各个实例节点上执行如下命令检查匿名事务是否消耗完毕，最好多检查几次，以便确认该参数的值是0.
[RW][TEST:3316]>SHOW STATUS LIKE ‘ONGOING_ANONYMOUS_TRANSACTION_COUNT’;
+————————————-+——-+
| Variable_name | Value |
+————————————-+——-+
| Ongoing_anonymous_transaction_count | 0 |
+————————————-+——-+
1 row in set (0.00 sec)
如果在从库上检查只需要一次满足为0 即可。
2.5 确保第四步之前的binlog全部为应用。
确保操作之前的所有binlog都已经被其他服务器应用了，因为匿名的GTID必须确保已经复制应用成功，才可以进行下一步操作。如何检查呢？ 其实最简单的方式是在从库库执行 show slave status 检查应用位点的情况。如果追上了，则可以继续。否则需要等待从库应用完binlog之后在进行下一步。
2.5 在主从复制结构中所有的实例中执行:
set global GTID_MODE = ON;
该参数的功能是让系统产生GTID ,Slave只能接受带GTID的事务。
2.6 在从库上执行:
设置slave 复制中 MASTER_AUTO_POSITION=1。
[RO][TEST:3316]>stop slave;
[RO][TEST:3316]>CHANGE MASTER TO MASTER_AUTO_POSITION = 1;
[RO][TEST:3316]>[RW][TEST:3316]>start slave;
至此，将基于位点的复制关系升级为GTID模式。结束了吗？还没呢，记得修改my.cnf 添加
gtid_mode = on
enforce_gtid_consistency = on
三 在线关闭GTID
关闭GTID的步骤其实和开启的步骤相反:
3.1 关闭slave 复制中的 MASTER AUTO POSITION
[RO][TEST:3316]>stop slave;
[RO][TEST:3316]>CHANGE MASTER TO MASTER_LOG_FILE = file,
MASTER_LOG_POS = position MASTER_AUTO_POSITION = 0;
[RO][TEST:3316]>[RW][TEST:3316]>start slave;
3.2 在所有的实例上执行:
set global GTID_MODE = ON_PERMISSIVE;
3.3 在所有的实例上执行:
set global GTID_MODE = OFF_PERMISSIVE;
3.4 等待 @@GLOBAL.GTID_OWNED 的值是一个空字符串为止。
SELECT @@GLOBAL.GTID_OWNED;
3.5 检查master上的binlog中的日志都已经被slave应用完毕
3.6 在所有实例上设置GTID_MODE 为off
set global GTID_MODE = OFF;
3.7 在所有实例上执行:
SET global GTID_MODE = OFF;
SET global ENFORCE_GTID_CONSISTENCY = OFF;
3.8 删除或者注释my.cnf中的GTID相关参数
从MySQL 5.6.5 开始新增了一种基于 GTID 的复制方式。通过 GTID 保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性，故障恢复以及容错能力。
GTID (Global Transaction ID)是全局事务ID,当在主库上提交事务或者被从库应用时，可以定位和追踪每一个事务，对DBA来说意义就很大了，我们可以适当的解放出来，不用手工去可以找偏移量的值了，而是通过CHANGE MASTER TO MASTER_HOST=’xxx’, MASTER_AUTO_POSITION=1的即可方便的搭建从库，在故障修复中也可以采用MASTER_AUTO_POSITION=‘X’的方式。
可能大多数人第一次听到GTID的时候会感觉有些突兀，但是从架构设计的角度，GTID是一种很好的分布式ID实践方式，通常来说，分布式ID有两个基本要求：
1）全局唯一性
2）趋势递增
这个ID因为是全局唯一，所以在分布式环境中很容易识别，因为趋势递增，所以ID是具有相应的趋势规律，在必要的时候方便进行顺序提取，行业内适用较多的是基于Twitter的ID生成算法snowflake,所以换一个角度来理解GTID，其实是一种优雅的分布式设计。
1。如何开启GTID
如何开启GTID呢，我们先来说下基础的内容，然后逐步深入，通常来说，需要在my.cnf中配置如下的几个参数：
①log-bin=mysql-bin
②binlog_format=row
③log_slave_updates=1
④gtid_mode=ON
⑤enforce_gtid_consistency=ON
其中参数log_slave_updates在5.7中不是强制选项，其中最重要的原因在于5.7在mysql库下引入了新的表gtid_executed。
在开始介绍GTID之前，我们换一种思路，通常我们都会说一种技术和特性能干什么，我们了解一个事物的时候更需要知道边界，那么GTID有什么限制呢，这些限制有什么解决方案呢，我们来看一下。
2。 GTID的限制和解决方案
如果说GTID在5.6试水，在5.7已经发展完善，但是还是有一些场景是受限的。比如下面的两个。
一个是create table xxx as select 的模式；另外一个是临时表相关的,我们就来简单说说这两个场景。
1）create 语句限制和解法
create table xxx as select的语句，其实会被拆分为两部分，create语句和insert语句，但是如果想一次搞定，MySQL会抛出如下的错误。
mysql> create table test_new as select *from test;
ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TABLE … SELECT.
这种语句其实目标明确，复制表结构，复制数据，insert的部分好解决，难点就在于create table的部分，如果一个表的列有100个，那么拼出这么一个语句来就是一个工程了。
除了规规矩矩的拼出建表语句之外，还有一个方法是MySQL特有的用法 like。
create table xxx as select 的方式可以拆分成两部分，如下。
create table xxxx like data_mgr;
insert into xxxx select *from data_mgr;
2）临时表的限制和建议
使用GTID复制模式时，不支持create temporary table 和 drop temporary table。但是在autocommit=1的情况下可以创建临时表，Master端创建临时表不产生GTID信息，所以不会同步到slave，但是在删除临时表的时候会产生GTID会导致，主从中断.
3。 从三个视角看待GTID
前面聊了不少GTID的内容，我们来看看GTID的一个体系内容，如下是我梳理的一个GTID的概览信息，分别从变量视图，表和文件视图，操作视图来看待GTID.
搞懂MySQL GTID原理
我们分别从每个视图来简单说下：
1）变量视图
我们来用下面的表格来阐述下常见的这几个变量
搞懂MySQL GTID原理
2）表和文件视图
先来说下文件层面的关联，根据MySQL的复制原理，MySQL Server在写binlog的时候，会先写一个特殊的Binlog Event，类型为GTID_Event，指定下一个事务的GTID，然后再写事务的Binlog，主从同步时GTID_Event和事务的Binlog都会传递到从库，在从库应用Relay Log,从库在执行的时候也是用同样的GTID写binlog.
然后说一下表mysql.gtid_executed,在5.6版本中必须要设置log_slave_updates,因为当slave重启后，无法得知当前slave已经运行到的GTID位置，因为变量gtid_executed是一个内存值，而这个问题在5.7中通过表mysql.gtid_executed把这个值持久化来得以解决，也就意味着log_slave_updates是一个可选项。
此外，引入该解决方案之后又带来了新的问题，那就是在gtid_executed里面的数据会越来越多，如何精简管理呢，MySQL引入了一个新的线程和参数来进行管理。
线程为：thread/sql/compress_gtid_table，可以查询performance_schema.threads来查看。
参数为 gtid_executed_compression_period ，主要用于控制每执行多少个事务，对表gtid_executed进行压缩，默认值为：1000 。
3）操作视图
对于操作，我们列举了较为简单常规的操作方式，为了避免歧义，我对一些命令做了取舍。
这些主要是在搭建主从复制关系时所用，基本都是一次开启，长期生效的方式。
如果是修复主从复制中的异常，如果是在确认错误可以跳过的情况下，可以使用如下的方式:
l stop slave；
l set gtid_next=’xxxxxxx:N’; –指定下一个事务执行的版本，即想要跳过的GTID
l begin;
l commit; –注入一个空事物
l set gtid_next=’AUTOMATIC’ –自动的寻找GTID事务。
l start slave; –开始同步
MySQL GTID简介
GTID（ Global Transaction Identifier）全局事务标识，由主库上生成的与事务绑定的唯一标识，这个标识不仅在主库上是唯一的，在MySQL集群内也是唯一的。GTID是 MySQL 5.6 版本引入的一个有关于主从复制的重大改进，相对于之前版本基于Binlog文件+Position的主从复制，基于GTID的主从复制，数据一致性更高，主从数据复制更健壮，主从切换、故障切换不易出错，很少需要人为介入处理。
MySQL GTID特点
事务提交产生GTID，GTID与事务及事务提交所在的节点绑定，GTID与事务一起写入Binlog，但是从库应用Binlog并不会生成新的GTID。
集群中的任何一个节点，根据其GTID值就可以知道哪些事务已经执行，哪些事务没有执行，如果发现某个GTID已执行，重复执行该GTID，将会被忽略，即同一个GTID只能被应用一次。
当一个连接执行一个特定GTID的事务，但是还没有提交，此时有另外一个连接也要执行相同GTID的事务，那么第二个连接的执行将会被阻塞，直到第一个事务提交或者回滚。如果第一个事务成功提交，第二个事务将会被忽略。如果第一个事务回滚，第二个事务正常执行。
如何开启GTID
gtid_mode=ON
enforce_gtid_consistency=ON
GTID长啥样
GTID = server_uuid:transaction_id
示例：3E11FA47-71CA-11E1-9E33-C80AA9429562:1
server_uuid标识了该事务执行的源节点，存储在数据目录中的auto.cnf文件中，transaction_id 是在该主库上生成的事务序列号，从1开始，示例中 3E11FA47-71CA-11E1-9E33-C80AA9429562 是这个节点的server_uuid，1为这个节点上提交的第1个事务的事务号，如果提交了10个事务，GTID会是这样： 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-10
GTID可以是一段连续或者不连续的几段事务序列集合，下面是可能出现的GTID模样：
3E11FA47-71CA-11E1-9E33-C80AA9429562:1
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-3:12:47-49
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-3, 24DA167-0C0C-11E8-8442-00059A3C7B00:1-19（多个节点提交事务，通常发生了主从切换）
GTID存储在什么地方？
GTID与事务绑定在一起，随着事务的提交，GTID随事务信息一起写入Binlog，通过主从复制，传递到从库。对于已经执行了的事务，其GTID通常会记录在MySQL的系统变量@@GLOBAL.gtid_executed 以及系统表mysql.gtid_executed中，系统变量@@GLOBAL.gtid_executed 在内存中，属于非持久化存储，而系统表mysql.gtid_executed属于持久化存储。
mysql.gtid_executed 表的更新。与Binlog有没有打开有关。
如果开启了Binlog，只有在 Binlog轮转或者MySQL关闭的时候，才会把Binlog中的GTID与入到mysql.gtid_executed表中。
如果没有开启Binlog，那么将通过 gtid_executed_compression_period 这个参数控制mysql.gtid_executed表的更新。默认值为1000，即每1000个事务，将mysql.gtid_executed表中的数据进行合并。 gtid_executed_compression_period设置为0，将不会进行合并，mysql.gtid_executed 表会变得越来越大，直到把磁盘用完。如果开启了Binlog，gtid_executed_compression_period这个参数将不再起作用。mysql.gtid_executed表的数据合并压缩由线程函数compress_gtid_table来执行，位于源码sql/rpl_gtid_persist.cc
extern “C” void *compress_gtid_table(void *p_thd);
该线程不在show processlist中展示，但是可以在 performance_schema.threads 表中看到。
SELECT * FROM performance_schema.threads WHERE NAME LIKE ‘%gtid%’\G
如果MySQL异常崩溃，GTID没来得及写入mysql.gtid_executed表中，那么在MySQL重新启动后，会从Binlog中搜索GTID，并将这一部分没有写入到mysql.gtid_executed表的GTID写入到表中。如果想查询最新的GTID提交情况，建议查询MySQL全局变量 @@GLOBAL.gtid_executed，而不是查询表 mysql.gtid_executed。
开始GTID后，Binlog存储事务和GTID信息，可以通过mysqlbinlog工具来解析，具体用法如下：
mysqlbinlog –start-datetime=”2017-03-21 10:20:00” –start-datetime=”2017-03-21 12:20:00” mysql-bin.000001 –base64-output=decode-rows -vvv > binlog.txt
GTID生命周期：
当一个事务在一个主库上被执行和提交，那么这个事务就会被分配一个和该主库uuid相关联的gtid，这个gtid被写入到主库的binlog文件中。
当这个binlog文件达到最大值发生轮转，或者MySQL Server关闭时，上一个binlog文件中的事务GTID将会被写入到mysql.gtid_executed表中。
事务提交时，该事务的gtid会很快的添加到系统变量 @@GLOBAL.gtid_executed，但是系统表 mysql.gtid_executed 则不会，因为有部分gtid还在binlog中，需要等到binlog轮转或者MySQL Server关闭时才会写入到mysql.gtid_executed表中。
主库上的binlog通过主从复制协议传送到从库，并写入到从库的relay log，从库读取relay log中的gtid和对应的事务信息，把gtid_next设置为该gtid值，使得从库使用该gtid值应用其对应的事务。
如果多个线程并发地应用同一个事物，比如多个线程设置gtid_next为同一个值，MySQL Server只允许其中一个线程执行，gtid_owned系统变量记录着谁拥有该GTID。
GTID Auto-Position:
GTID之前的主从复制是基于文件+偏移的方式，建立主从复制，必须先知道主库的binlog文件和偏移位置（ MASTER_LOG_FILE 和 MASTER_LOG_POS）。而使用基于GTID的主从复制，设置 MASTER_AUTO_POSITION =1，从库发送自身已经接收到的gtid给主库，主库将从库缺失的gtid及其对应的binlog文件发送给从库，也就是主库只发送从库没有接收到的事务。所有的信息由MySQL集群自动获取完成，不需要人为干预，大大简化了复制搭建过程。
如果主库要发送给从库的GTID所在的binlog已经被清除了，或者这些gtid已经被添加到gtid_purged，那么主库将发送错误信息给从库，复制将会中断。通常发生这种情况时，从库可以更换复制源，或者使用最新的备份来重建复制。也可以考虑修改增加主库binlog文件的过期时间来减少这种情况的发生。
如果从库已经接收到的gtid 比主库的gtid要多，那么主库也将发送错误信息给从库，同时复制中断。这种情况一般是主库没有设置 sync_binlog=1 ，此时主库发生断电、宕机等故障，导致主库的binlog没有刷到磁盘，而从库已经接收到了主库的binlog。这种情况一般需要人工介入解决，所以推荐更安全的sync_binlog=1 。
基于GTID的复制搭建：
CHANGE MASTER TO MASTER_HOST=’127.0.0.1’, MASTER_PORT=3306,MASTER_USER=’repl’, MASTER_PASSWORD=’123456’,MASTER_AUTO_POSITION=1;
基于Binlog+Position的复制搭建：
CHANGE MASTER TO MASTER_HOST=’127.0.0.1’, MASTER_PORT=3306, MASTER_USER=’repl’, MASTER_PASSWORD=’123456’,MASTER_LOG_FILE=’mysql-bin.000001’,MASTER_LOG_POS=524;
GTID相关函数：
GTID_SUBSET(set1,set2)
如果set1是set2的子集，返回true，否则返回false
GTID_SUBTRACT(set1,set2)
返回set1与set2的差集，即GTID在set1中，不在set2中。
WAIT_FOR_EXECUTED_GTID_SET(gtid_set[, timeout])
等待GTID执行到某一个位置，如果指定timeout参数，在timeout时间之内，gtid没有执行到该位置 ，则报错返回。
WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(gtid_set[, timeout][,channel])
等待复制线程（SQL_Thread)执行GTID到某一个位置，同样可以指定超时时间timeout。
MySQL 开启 GTID 导致拒绝 Anoymous GTID Binlog 同步请求，可能会跳过部分 Binlog
