一 基于全局事务标识符GTID复制
1.1 GTID介绍
1.2 GTID格式和存储
1.3 GTID集
1.4 mysql.gtid_executed表说明
1.5 mysql.gtid_executed表压缩
1.6 GTID的生命周期
二、MySQL使用GTID进行复制
2.1 master的配置
2.2 slave使用简单复制
2.3 slave2通过数据和事务复制
三、使用GTID复制的限制
以下实验及文档说明，全部来源与官方文档官网手册
https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html
一 基于全局事务标识符GTID复制
1.1 GTID介绍
使用GTID时，每次数据的变动都可以提交到原始服务器上并由任何副本应用时进行标识和跟踪。这意味着在启动新的slave或故障转移到master时，使用GTID引用日志文件或这些文件中的位置时没有必要(这也是基于二进制日志文件复制的缺陷)，这极大地简化了这些任务。由于基于GTID的复制完全基于事务，因此很容易确定源和副本是否一致；只要在master上提交的所有事务也都在副本上提交，则可以保证两者之间的一致性。可以对GTID使用基于语句的复制或基于行的复制，为了获得最佳结果，建议使用基于行的格式(mysql5.7默认值 binlog_format=ROW)。
GTID始终在master和slave之间保存。这意味着您始终可以通过检查二进制日志来确定应用于任何副本的任何事务的源。此外，一旦在给定服务器上提交了具有给定GTID的事务，该服务器将忽略具有相同GTID的任何后续事务。因此，在源上提交的事务只能在副本上应用一次以上，这有助于确保一致性。
1.2 GTID格式和存储
全局事务标识符（GTID）是创建的唯一标识符，并且与在master上提交的每个事务相关联。该GTID再master和slave上都是唯一的。
GTID分配区分在master上提交的客户端事务和在slave上重现的复制事务。如果将客户端事务提交到master上，则将为其分配一个新的GTID，前提是该事务已写入二进制日志中。保证客户交易具有单调增加的GTID，而在生成的数字之间没有间隙。如果没有将客户事务写入二进制日志中（例如，由于该事务被滤除或该事务为只读），则不会在原始服务器上为其分配GTID。
slave和master上具有相同的GTID。GTID在复制的事务开始执行之前就存在，并且即使复制的事务未写入副本上的二进制日志或在副本上被过滤掉，GTID也会保留。MySQL系统表mysql.gtid_executed用于保留MySQL服务器上应用的所有事务的已分配GTID，但存储在当前活动的二进制日志文件中的事务除外(这个事务没有提交)。
GTID的自动跳过功能：意味着在源上提交的事务只能在副本上应用一次，这有助于确保一致性。一旦将具有给定GTID的事务提交到给定服务器上，则该服务器将忽略执行具有相同GTID的后续事务的任何尝试。不会引发任何错误，并且不会执行事务中的任何语句。
如果具有给定GTID的事务已开始在服务器上执行，但尚未提交或回滚，则在具有相同GTID的服务器上启动并发事务的任何尝试都将被阻止。服务器既不开始执行并发事务，也没有将控制权返回给客户端。一旦对事务的第一次尝试提交或回滚，在同一GTID上阻塞的并发会话可能会继续进行。如果第一次尝试回滚，则一个并发会话将继续尝试事务，并且在同一GTID上阻塞的任何其他并发会话将保持阻塞状态。如果首次尝试提交，则所有并发会话都将停止阻塞，并自动跳过事务的所有语句。
GTID的存储格式：
GTID = source_id:transaction_idsource_id表示服务器的UUID值transaction_id是通过在事务提交到master的顺序确定一个序列号。事务的GTID显示再mysqlbinlog的输出中，通过mysqlbinlog binlog_file查看，用于标识复制状态表中的单个事务gtid_next系统变量存储的值是单个GTID。
1.3 GTID集
GTID集是包括一个或多个单个GTID或一系列GTID的集。由gtid_executed和 gtid_purged系统变量存储的值是GTID集。该START SLAVE 选项UNTIL SQL_BEFORE_GTIDS和 UNTIL SQL_AFTER_GTIDS可用于制作副本处理的gitd范围。内置的功能GTID_SUBSET()和 GTID_SUBTRACT()需要GTID集作为输入。
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5 //表示单个服务器gtid范围3E11FA47-71CA-11E1-9E33-C80AA9429562:1-3:11:47-49 //表示单个服务器的多个或者单个GTID范围2174B383-5441-11E8-B90A-C80AA9429562:1-3, 24DA167-0C0C-11E8-8442-00059A3C7B00:1-19 //表示不通服务器的gtid范围
1.4 mysql.gtid_executed表说明
GTID存储在数据库中名为的表 gtid_executed中 mysql。该表中的一行包含它代表的每个GTID或一组GTID，始发服务器的UUID以及该组的开始和结束事务ID。对于仅引用单个GTID的行，最后两个值相同。
mysql> select * from mysql.gtid_executed;+--------------------------------------+----------------+--------------+| source_uuid | interval_start | interval_end |+--------------------------------------+----------------+--------------+| f0038947-e8ce-11ea-b714-000c2992efe2 | 1 | 88 |+--------------------------------------+----------------+--------------+1 row in set (0.00 sec)
GTID的存储点取决于是否启用了二进制日志记录：
如果禁用了二进制日志记录（log_binis OFF），或者如果 log_slave_updates禁用了二进制日志记录，则服务器将属于每个事务的GTID与该事务一起存储在表中。另外，该表以用户可配置的速率定期压缩。这种情况仅适用于禁用了二进制日志记录或副本更新日志记录的副本。它不适用于复制源服务器，因为必须在源上启用二进制日志记录才能进行复制。
如果启用了二进制日志记录（log_bin是 ON），则每当刷新二进制日志或关闭服务器时，服务器都会将写入前一个二进制日志的所有事务的GTID写入mysql.gtid_executed表中。这种情况适用于复制源服务器或启用了二进制日志记录的副本。
如果服务器意外停止，则当前的二进制日志文件中的GTID集不会保存再此表中。在恢复期间，这些GTID从二进制日志文件添加到表中，如果未启用二进制日志记录，这种情况下无法访问二进制日志，就不能恢复GTID，更不能进行复制了。
启用二进制日志记录后，该 mysql.gtid_executed表不会保存所有已执行事务的GTID的完整记录。该信息由gtid_executed系统变量的全局值提供 。始终使用 @@GLOBAL.gtid_executed，它在每次提交后都会更新，以表示MySQL服务器的GTID状态，而不查询该 mysql.gtid_executed表。
1.5 mysql.gtid_executed表压缩
随着时间的流逝， mysql.gtid_executed表中可能会出现很多行，这些行引用了源自同一服务器的各个GTID，并且它们的事务ID构成了一个范围，类似于此处显示的内容：
+--------------------------------------+----------------+--------------+| source_uuid | interval_start | interval_end ||--------------------------------------+----------------+--------------|| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37 | 37 || 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 38 | 38 || 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 39 | 39 || 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 40 | 40 || 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 41 | 41 || 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 42 | 42 || 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 43 | 43 |...
为了节省空间，MySQL服务器mysql.gtid_executed通过用横跨事务标识符整个间隔的一行替换每行这样的行来定期压缩表，如下所示：
+--------------------------------------+----------------+--------------+| source_uuid | interval_start | interval_end ||--------------------------------------+----------------+--------------|| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37 | 43 |
通过设置gtid_executed_compression_period 系统变量，可以控制在压缩表之前允许经过的事务数，从而控制压缩率 。此变量的默认值为1000，这意味着默认情况下，每1000个事务处理后将执行表压缩。设置 gtid_executed_compression_period 为0根本无法执行压缩，gtid_executed如果您这样做，则应该准备增加表可能需要的磁盘空间量
mysql> show variables like 'gtid_executed%';+----------------------------------+-------+| Variable_name | Value |+----------------------------------+-------+| gtid_executed_compression_period | 1000 |+----------------------------------+-------+1 row in set (0.01 sec)注意：启用二进制日志时，这个值不使用，并且mysql.gtid_executed表上的每个二进制日志循环重复压缩。SELECT * FROM performance_schema.threads WHERE NAME LIKE '%gtid%'\G 这个压缩有这个线程控制
1.6 GTID的生命周期
内容比较多，请参考官网说明：
https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-lifecycle.html
二、MySQL使用GTID进行复制
maste(48.180)---slave(48.181)
---slave1(48.182)
2.1 master的配置
1.配置文件修改[root@master ~]# cat /etc/my.cnf[mysqld]datadir=/databasedir=/opt/mysqlsocket=/data/mysql.socklog-bin=master-binsync-binlog=1 //每次提交事务将缓存中的binlog刷新到磁盘server-id=100enforce_gtid_consistency=on //使用gtid必须配置，启用该变量确保仅记录对基于GTID的复制安全的语句gtid_mode=on //使用gtid必须配置[mysqld_safe]log-error=/opt/mysql/mysql.errpid-file=/opt/mysql/mysql.pid2. 创建复制用户grant replication slave on *.* to repl@'%' identified by '123456';
2.2 slave使用简单复制
在新服务器上重现所有标识符和事务的最简单方法是使新服务器成为具有完整执行历史记录的源副本，并在两个服务器上启用全局事务标识符。复制开始后，slave将从master获取整个二进制日志，从而获得所有GTID的信息。这种方法简单高效，但是在执行复制过程耗时会较长，因此此方法不适合用于快速故障转移或从备份还原。(此方法适用于当master没有删除过任何binlog时(binlog按顺序排列)，可以随意地向复制结构中添加新的slave，因为slave会复制所有的binlog到自己relay log中并replay)
1)slave的配置文件(可以不开启二进制日志记录)[root@slave ~]# cat /etc/my.cnf[mysqld]datadir=/datasocket=/data/mysql.sockrelay-log=slave-binserver-id=200basedir=/opt/mysql/sync-binlog=1log-bin=master-slave-bin //mysql5.7不是必须，mysql5.6必须开启binlogenforce_gtid_consistency=on //强制要求只允许复制事务安全的事务gtid_mode=on //是否开启gtid模式[mysql_safe]log-error=/opt/mysql/slave.errpid-file=/run/mysl.pid3)slave配置连接参数mysql> change master to->master_host='192.168.48.180',->master_port=3306,->master_user='repl',->master_password='123456',->master_auto_position=1;mysql> show processlist;+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+| Id | User | Host | db | Command | Time | State | Info |+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+| 5 | root | localhost | NULL | Query | 0 | starting | show processlist || 6 | system user | | NULL | Connect | 6 | Waiting for master to send event | NULL || 7 | system user | | NULL | Connect | 6 | Slave has read all relay log; waiting for more updates | NULL |+----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+3 rows in set (0.00 sec)3) master上插入数据查看复制是否生效mysql> call proc_num1(1000000);Query OK, 475712 rows affected (6.61 sec)mysql> call proc_num2(1000000);Query OK, 475712 rows affected (13.33 sec)4）slave上面查看复制状态mysql> show slave status \G*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 192.168.48.180Master_User: replMaster_Port: 3306Connect_Retry: 60Master_Log_File: master-bin.000013 //master的binlog日志Read_Master_Log_Pos: 10055282 //读取到的master的位置Relay_Log_File: slave-bin.000002Relay_Log_Pos: 10055497Relay_Master_Log_File: master-bin.000013 //master的binlog日志Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 10055282 //最后读取到的master的位置一致Relay_Log_Space: 10055698Until_Condition: NoneUntil_Log_File:Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: NoLast_IO_Errno: 0Last_IO_Error:Last_SQL_Errno: 0Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id: 100Master_UUID: f0038947-e8ce-11ea-b714-000c2992efe2Master_Info_File: /data/master.infoSQL_Delay: 0SQL_Remaining_Delay: NULLSlave_SQL_Running_State: Slave has read all relay log; waiting for more updatesMaster_Retry_Count: 86400Master_Bind:Last_IO_Error_Timestamp:Last_SQL_Error_Timestamp:Master_SSL_Crl:Master_SSL_Crlpath:Retrieved_Gtid_Set: f0038947-e8ce-11ea-b714-000c2992efe2:1-44 //uuid:gtid(前面是serverID)，1-44是gtid的位置Executed_Gtid_Set: f0038947-e8ce-11ea-b714-000c2992efe2:1-44Auto_Position: 1Replicate_Rewrite_DB:Channel_Name:Master_TLS_Version:1 row in set (0.00 sec)
2.3 slave2通过数据和事务复制
当master以前处理大量事务时，执行整个事务历史记录可能很耗时，这可能是设置新副本时的主要瓶颈。为了消除此问题，可以将master的数据集备份，把二进制日志和全局事务信息导入到新slave中。在复制数据之前，必须确保master上已处理所有必需的事务
（比如当master删除过一部分binlog后，在向复制结构中添加新的slave时，必须先获取到master binlog中当前已记录的第一个gtid之前的所有数据，然后恢复到slave上。只有slave上具有了这部分基准数据，才能保证和master的数据一致性。)在实际生产环境中，往往会定期删除一部分binlog。所以，为了配置更通用的gtid复制环境，这里把前文的master的binlog给purge掉一部分。
1.查看当前master的binlog的使用情况[root@master ~]# ll /data/*bin*-rw-r----- 1 mysql mysql 177 8月 28 09:36 /data/master-bin.000001-rw-r----- 1 mysql mysql 154 8月 28 09:48 /data/master-bin.000002-rw-r----- 1 mysql mysql 996 8月 28 09:51 /data/master-bin.000003-rw-r----- 1 mysql mysql 612 8月 28 09:53 /data/master-bin.000004-rw-r----- 1 mysql mysql 10057961 8月 28 23:48 /data/master-bin.000005-rw-r----- 1 mysql mysql 202 8月 28 23:54 /data/master-bin.000006-rw-r----- 1 mysql mysql 507175056 8月 29 14:31 /data/master-bin.000007-rw-r----- 1 mysql mysql 177 8月 29 14:32 /data/master-bin.000008-rw-r----- 1 mysql mysql 177 9月 1 11:44 /data/master-bin.000009-rw-r----- 1 mysql mysql 202 9月 1 12:05 /data/master-bin.000010-rw-r----- 1 mysql mysql 177 9月 1 12:06 /data/master-bin.000011-rw-r----- 1 mysql mysql 55249955 9月 2 16:23 /data/master-bin.000012-rw-r----- 1 mysql mysql 10055282 9月 2 16:45 /data/master-bin.000013-rw-r----- 1 mysql mysql 260 9月 2 16:39 /data/master-bin.index2.purge已有的binlogmysql> flush logs; //刷新binlog日志，会重新生成一个binlogmysql> purge master logs to 'master-bin.000014'; //清楚新增的binlog之前的所有日志[root@master ~]# ll /data/*bin*-rw-r----- 1 mysql mysql 194 9月 2 16:54 /data/master-bin.000014-rw-r----- 1 mysql mysql 20 9月 2 16:55 /data/master-bin.index3.slave2的配置[root@slave2 data]# cat /etc/my.cnf[mysqld]datadir=/databasedir=/opt/mysqlsocket=/data/mysql.socksync-binlog=1relay-log=slave2-binserver-id=300log-bin=master-slave-binenforce_gtid_consistency=ongtid_mode=on[mysqld_safe]log-error=/opt/mysql/slave2.log4.备份master的数据[root@master ~]# mysqldump -h127.0.0.1 -p -S /data/mysql.sock --single-transaction --all-databases --master-data=2 --set-gtid-purged=ON> mysql-20200902.db//说明：--master-data=2使备份中带有二进制日志信息的语句(默认1，2是二进制信息作为注释信息)--set-gtid-purged=ON在转储中包含已执行事务的信息--single-transaction 在转储中不进行锁表这里使用的mysqldump，也可以执行冷备份，直接停止master和slave，将master的数据目录拷贝到slave。这种方法要求slave需要提前开启gtid_mode=ON5.在slave2恢复数据[root@slave2 ~]# mysql -uroot -p -S /data/mysql.sock < mysql-20200902.dbEnter password:在启动slave线程之前需要在master上获取gtid_purged的值，用来在slave上指定需要跳过gtid的集合。要设置gtid_executed值必须保证全局gtid_executed为空，所以要在slave上执行reset master，在设置gtid_purged在master上查询gtid_purged 的值mysql> show global variables like "%gtid%";+----------------------------------+-------------------------------------------+| Variable_name | Value |+----------------------------------+-------------------------------------------+| binlog_gtid_simple_recovery | ON || enforce_gtid_consistency | ON || gtid_executed | f0038947-e8ce-11ea-b714-000c2992efe2:1-44 |//已经执行过的gtid，reset master会清空该项的值| gtid_executed_compression_period | 1000 || gtid_mode | ON || gtid_owned | || gtid_purged | f0038947-e8ce-11ea-b714-000c2992efe2:1-44 |//已经purge掉的gtid，要设置这个值，必须保证gtid_executed的值为空，slave上的此值应该等与gtid_executed的值| session_track_gtids | OFF |+----------------------------------+-------------------------------------------+8 rows in set (0.00 sec)//这里说明下。gtid的集合1-44表示这44个事务是已经执行过的mysql> reset master;Query OK, 0 rows affected (0.02 sec)mysql> set @@GLOBAL.GTID_PURGED='f0038947-e8ce-11ea-b714-000c2992efe2:1-44';Query OK, 0 rows affected (0.00 sec)mysql> change master to->master_host='192.168.48.180',->master_port=3306,->master_user='repl',->master_password='123456',->master_auto_position=1;6.查看slave的状态mysql> show slave status \G*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 192.168.48.180Master_User: replMaster_Port: 3306Connect_Retry: 60Master_Log_File: master-bin.000014Read_Master_Log_Pos: 194Relay_Log_File: slave2-bin.000002Relay_Log_Pos: 369Relay_Master_Log_File: master-bin.000014Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 194Relay_Log_Space: 571Until_Condition: NoneUntil_Log_File:Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: NoLast_IO_Errno: 0Last_IO_Error:Last_SQL_Errno: 0Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id: 100Master_UUID: f0038947-e8ce-11ea-b714-000c2992efe2Master_Info_File: /data/master.infoSQL_Delay: 0SQL_Remaining_Delay: NULLSlave_SQL_Running_State: Slave has read all relay log; waiting for more updatesMaster_Retry_Count: 86400Master_Bind:Last_IO_Error_Timestamp:Last_SQL_Error_Timestamp:Master_SSL_Crl:Master_SSL_Crlpath:Retrieved_Gtid_Set:Executed_Gtid_Set: da9e6bae-ecfc-11ea-b170-000c29bd1514:1-152,f0038947-e8ce-11ea-b714-000c2992efe2:1-44Auto_Position: 1Replicate_Rewrite_DB:Channel_Name:Master_TLS_Version:1 row in set (0.00 sec)7.master上面添加数据看是否同步到slave和slave2mysql> call proc_num1(1000000);截取关键信息slave的状态Master_Log_File: master-bin.000014Read_Master_Log_Pos: 5028240Relay_Log_File: slave-bin.000004Relay_Log_Pos: 5028455Relay_Master_Log_File: master-bin.000014Exec_Master_Log_Pos: 5028240 //已经同步Relay_Log_Space: 5028744Retrieved_Gtid_Set: f0038947-e8ce-11ea-b714-000c2992efe2:1-66Executed_Gtid_Set: f0038947-e8ce-11ea-b714-000c2992efe2:1-66slave2的状态Master_Log_File: master-bin.000014Read_Master_Log_Pos: 5028240Relay_Log_File: slave2-bin.000002Relay_Log_Pos: 5028415Relay_Master_Log_File: master-bin.000014Exec_Master_Log_Pos: 5028240 //已经同步Relay_Log_Space: 5028617Retrieved_Gtid_Set: f0038947-e8ce-11ea-b714-000c2992efe2:45-66Executed_Gtid_Set: da9e6bae-ecfc-11ea-b170-000c29bd1514:1-152,f0038947-e8ce-11ea-b714-000c2992efe2:1-66Auto_Position: 18.回到master，purge掉已经同步的binlog当slave指定的gtid_purged实现同步后，为了下次重启mysql不用再次设置@@gtid_purged,所以应该在master上面将同步的binlog给pured掉mysql> flush logs;mysql> purge master logs to "master-bin.000015"; //后面slave2就不必重新设置gtid_purged，因为在上面操作中，已经进行了相关同步现在测试下上面所说的结论[root@slave2 ~]# /etc/init.d/mysqld stopShutting down MySQL.. SUCCESS![root@slave2 ~]# /etc/init.d/mysqld startStarting MySQL. SUCCESS![root@slave ~]# /etc/init.d/mysqld stopShutting down MySQL.. SUCCESS![root@slave ~]# /etc/init.d/mysqld startShutting down MySQL.. SUCCESS!mysql再次插入数据，可以看到已经同步mysql> call proc_num1(1000000);slave1Master_Log_File: master-bin.000015Read_Master_Log_Pos: 5028240Relay_Log_File: slave-bin.000008Relay_Log_Pos: 5028455Relay_Master_Log_File: master-bin.000015Exec_Master_Log_Pos: 5028240Relay_Log_Space: 5028696Retrieved_Gtid_Set: f0038947-e8ce-11ea-b714-000c2992efe2:1-110Executed_Gtid_Set: f0038947-e8ce-11ea-b714-000c2992efe2:1-110slave2Master_Log_File: master-bin.000015Read_Master_Log_Pos: 5028240Relay_Log_File: slave-bin.000008Relay_Log_Pos: 5028455Relay_Master_Log_File: master-bin.000015Exec_Master_Log_Pos: 5028240Relay_Log_Space: 5028696Retrieved_Gtid_Set: f0038947-e8ce-11ea-b714-000c2992efe2:1-110Executed_Gtid_Set: da9e6bae-ecfc-11ea-b170-000c29bd1514:1-152,f0038947-e8ce-11ea-b714-000c2992efe2:1-66Auto_Position: 19.master上查看到两个slave节点mysql> show slave hosts;+-----------+------+------+-----------+--------------------------------------+| Server_id | Host | Port | Master_id | Slave_UUID |+-----------+------+------+-----------+--------------------------------------+| 300 | | 3306 | 100 | da9e6bae-ecfc-11ea-b170-000c29bd1514 || 200 | | 3306 | 100 | 361eb334-e8d3-11ea-93ee-000c2930b5bd |+-----------+------+------+-----------+--------------------------------------+2 rows in set (0.00 sec)
总结：
Retrieved_Gtid_Set：开启了gtid复制时，slave在启动io线程的时候会检查relay log，并从中检索gtid集合。表示已经从master中复制了哪些事务过来，检索出来的gtid不再请求master发送过来。
Executed_Gtid_Set：开启了gtid复制时，表示已经向自己的binlog中写入了哪些gtid集合。注意，这个值是根据一些状态信息计算出来的，并非binlog中能看到的那些。比如slave的binlog还是空的，但这里已经显示一些已经执行的gtid的集合。
Auto_Position：开启gtid时是否自动获取binlog的坐标，1表示开启，这是gtid复制的默认值。
三、使用GTID复制的限制
涉及非事务性存储引擎的更新：不能将事务类型和非事务类型的存储引擎混合使用，混合使用的话可能会导致将多个GTID分配给同一事务。
CREATE TABLE ... SELECT语句：使用GTID时，不允许使用这些语句。
临时表：使用GTID时，事务，过程，函数和触发器内部不支持CREATE TEMPORARY TABLEand DROP TEMPORARY TABLE语句
防止执行不受支持的语句： 为防止执行会导致基于GTID的复制失败的语句，--enforce-gtid-consistency在启用GTID时，必须使用该选项启动所有服务器 。这个变量只有在执行二进制日志记录时才生效(没有开启或者过滤器过滤掉的语句没有写入二进制日志的都不会强制检查未执行语句的GTID一致性)。
跳过事务： sql_slave_skip_counter使用GTID时不支持。如果需要跳过事务，请改用源gtid_executed变量的值
忽略服务器:CHANGE MASTER TO使用GTID时,不建议使用 该语句的IGNORE_SERVER_IDS选项，因为已应用的事务将被自动忽略。在开始基于GTID的复制之前，请检查并清除以前在相关服务器上设置的所有忽略的服务器ID列表。该 SHOW SLAVE STATUS语句可以针对单个通道发出,如果存在则会显示被忽略的服务器ID的列表.如果没有列表则该 Replicate_Ignore_Server_Ids字段为空白。
GTID模式和mysqldump：如果目标服务器的二进制日志中没有GTID ，则可以将使用mysqldump创建的转储导入 到启用了GTID模式的MySQL服务器中。
GTID模式和mysql_upgrade:当服务器在启用（gtid_mode=ON）的全局事务标识符（GTID）的情况下运行时，请勿通过mysql_upgrade(该--write-binlog 选项)启用二进制日志记录。
