和传统基于位置的主从不同，如果从库报错我们需要获得从库执行的最后一个事物，方法有如下：

show slave status \G 中的 Executed_Gtid_Set。

show global variables like '%gtid%'; 中的 gtid_executed 。

show master status;中的Executed_Gtid_Set。

然后构建一个空事物如下：

stopslave;setgtid_next='4a6f2a67-5d87-11e6-a6bd-000c29a879a3:34';begin;commit;setgtid_next='automatic';startslave;

如果是多个如下：

stopslave;setgtid_next='89dfa8a4-cb13-11e6-b504-000c29a879a3:3';begin;commit;setgtid_next='89dfa8a4-cb13-11e6-b504-000c29a879a3:4';begin;commit;setgtid_next='automatic';startslave;

二、 mysqldump导出行为的改变

使用mysqldump受到选项set-gtid-purged=AUTO的影响，假如我们在Gtid开启和关闭的情况下使用如下语句导出数据：

mysqldump--single-transaction--master-data=2-R-E--triggers--all-databases

在Gtid开启的情况下会多如下设置：

SET@MYSQLDUMP_TEMP_LOG_BIN=@@SESSION.SQL_LOG_BIN;SET@@SESSION.SQL_LOG_BIN=0;----GTIDstateatthebeginningofthebackup--SET@@GLOBAL.GTID_PURGED='ec9bdd78-a593-11e7-9315-5254008138e4:1-105';

为什么要这么设置呢？因为如果做基于Gtid的主从，是否生成binlog就意味着在导入数据的时候是否基于本地数据库生成新的Gtid事物，显然这是不合理的，所以将SQL_LOG_BIN设置为0是必须的。接着GTID_PURGED被设置为备份时刻已经执行过的Gtid事物，如前文第五节源码剖析设置GTID_PURGED会设置三个地方的Gtid如下:

mysql.gtid_executed表

gtid_purge变量

gtid_executed变量

看起来是合理的，但是如果这里忽略了整个mysql.gtid_executed表是innodb表，导入过程中某些版本(已知percona 5.7.14，5.7.17)会重新删除和建立，因此通过GTID_PURGED设置的mysql.gtid_executed表会重新改变，重启数据库后需要读取mysql.gtid_executed表可能获得错误Gtid集合导致复制错误。这也为我的故障案例埋下了伏笔，案例中在详细描述。
当然也可以使用 --set-gtid-purged=OFF选项来告诉mysqldump不需要加入SQL_LOG_BIN= 0和GTID_PURGED，但是初始化搭建基于Gtid的主从一定不要设置为OFF。下面是这个选项的含义。

--set-gtid-purged[=name]Add'SET@@GLOBAL.GTID_PURGED'totheoutput.PossiblevaluesforthisoptionareON,OFFandAUTO.IfONisusedandGTIDsarenotenabledontheserver,anerrorisgenerated.IfOFFisused,thisoptiondoesnothing.IfAUTOisusedandGTIDsareenabledontheserver,'SET@@GLOBAL.GTID_PURGED'isaddedtotheoutput.IfGTIDsaredisabled,AUTOdoesnothing.Ifnovalueissuppliedthenthedefault(AUTO)valuewillbeconsidered.

三、5.7中搭建基于Gtid的主从

这里存在一个注意点，也是我案例中会提到的。我们还是直接说步骤

注意主备库必须开启Gtid和设置好server_id

enforce_gtid_consistency=ONgtid_mode=ONserver_id=9910binlog_format=row

同时主备库都开启binlog如果不设置级联从库，从库不要设置log_slave_updates参数。
这是最合理的设置。

建立复制用户

CREATEUSER'repl'@'%'IDENTIFIEDBY'test123';GRANTREPLICATIONSLAVEON*.*TO'repl'@'%';

导出数据

mysqldump--single-transaction--master-data=2-R-E--triggers--all-databases>test.sql

从库导入数据
source即可。

从库执行reset master语句
这一步主要防止gtid_executed被更改过。这个问题在在percona 5.7.14 5.7.17存在但是在percona 5.7.15 5.7.19又不存在。所以为了安全还是执行下面的两步。

resetmaster；

提取GTID_PURGED，并且执行
使用head -n 40 命令可以快速的得到比如我这里的

----GTIDstateatthebeginningofthebackup--SET@@GLOBAL.GTID_PURGED='ec9bdd78-a593-11e7-9315-5254008138e4:1-21';

执行

SET@@GLOBAL.GTID_PURGED='ec9bdd78-a593-11e7-9315-5254008138e4:1-21';

语句即可，完成本部分mysql.gtid_executed表会重构。

使用MASTER_AUTO_POSITION建立同步

changemastertomaster_host='192.168.99.41',master_user='repl',master_password='test123',master_port=3310,MASTER_AUTO_POSITION=1;

启动slave

startslave

四、5.7中Gtid的主从的切换

切换中必须要确认从库(新主库)没有做过本地的事物，如果做过，否则切换主库(新从库)需要拉取这一部分的Gtid事物，如果这些binlog已经不存在了那么势必会报错。这种情况下还是从建从库吧。那么我们来说正常的切换步骤。

从库(新主库)

stopslave;resetslaveall;

主库(新从库)

changemastertomaster_host='192.168.99.40',master_user='repl',master_password='test123',master_port=3310,MASTER_AUTO_POSITION=1;startslave;

实际就这么简单，从库(新主库)会生成自己的Gtid事物，新主库接受到后执行即可。此时会出现如下有两个server_uuid对应的Gtid，如下的gtid_executed

mysql>showglobalvariableslike'%gtid%';+----------------------------------+-------------------------------------------------------------------------------------+|Variable_name|Value|+----------------------------------+-------------------------------------------------------------------------------------+|binlog_gtid_simple_recovery|ON||enforce_gtid_consistency|ON||gtid_executed|31704d8a-da74-11e7-b6bf-525400a7d243:1-9,ec9bdd78-a593-11e7-9315-5254008138e4:1-25||gtid_executed_compression_period|1000||gtid_mode|ON||gtid_owned|||gtid_purged|ec9bdd78-a593-11e7-9315-5254008138e4:1-25||session_track_gtids|OFF|+----------------------------------+-------------------------------------------------------------------------------------+

总的说来如果要作为的切换的从库，不要在从库本地做任何事物。如果确实要做比如加索引等不影响数据的操作可以是使用如下：

mysql>setsql_log_bin=0;QueryOK,0rowsaffected(0.00sec)mysql>createindextest_jjjonjjj(id);QueryOK,0rowsaffected(0.42sec)Records:0Duplicates:0Warnings:0

这样也是不会增加本地Gtid的。

五、在线修改Gtid模式

这是5.7.6以后实现的功能其主要依赖了我们前面分析的 Previous gtid Event以及参数gtid_mode新加入的2个值。我们具体来看看gitd_mode各个值的含义：

OFF(0): Both new and replicated transactions must be anonymous.(生成的是匿名事物，slave也只能应用匿名事物)

OFF_PERMISSIVE:(1) New transactions are anonymous. Replicated transactions can be either
anonymous or GTID transactions.(生成的是匿名事物，slave可以应用匿名和GTID事物)

ON_PERMISSIVE(2): New transactions are GTID transactions. Replicated transactions can be either
anonymous or GTID transactions.(生成的是GTID事物，slave可以应用匿名和GTID事物)

ON(3): Both new and replicated transactions must be GTID transactions(生成的是GTID事物，slave也只能应用GTID事物)

注意每次修改值必然导致一次binlog的切换，如果发生binlog删除也能够依托 Previous gtid Event快速准确的找到gtid_purged(Gtid_state.lost_gtids)。

在线启动

主库/从库执行

SET@@GLOBAL.ENFORCE_GTID_CONSISTENCY=WARN;

确定事物都支持gtid，不会在err log中出现警告如下：
2017-02-26T22:35:24.322055Z 55 [Warning] Statement violates GTID consistency: CREATE TABLE ... SELECT.

主库/从库执行

SET@@GLOBAL.ENFORCE_GTID_CONSISTENCY=ON;

主库/从库执行

SET@@GLOBAL.GTID_MODE=OFF_PERMISSIVE;

生成的是匿名事物，slave可以应用匿名和GTID事物

主库/从库执行

SET@@GLOBAL.GTID_MODE=ON_PERMISSIVE;

生成的是GTID事物，slave可以应用匿名和GTID事物

主库/从库执行

确定已经没有匿名的事物

SHOWGLOBALSTATUSLIKE'ONGOING_ANONYMOUS_TRANSACTION_COUNT';

同时确认从库
Retrieved_Gtid_Set
Executed_Gtid_Set
正常增长

到这一步实际上gtid事物已经开始使用了。

主库/从库执行

SET@@GLOBAL.GTID_MODE=ON;

从库执行

stopslave;CHANGEMASTERTOMASTER_AUTO_POSITION=1;startslave;

主库/从库执行
修改配置文件my.cnf，将参数的更改加入到配置文件

在线关闭

从库执行

stopslave;

记录从库执行状态值

Exec_Master_Log_Pos:7631438Relay_Master_Log_File:bin_log.000016

执行

CHANGEMASTERTOMASTER_AUTO_POSITION=0,MASTER_LOG_FILE='bin_log.000016',MASTER_LOG_POS=7631438startslave;

主库/从库执行

SET@@GLOBAL.GTID_MODE=ON_PERMISSIVE;

生成的是GTID事物，slave可以应用匿名和GTID事物

主库/从库执行

SET@@GLOBAL.GTID_MODE=OFF_PERMISSIVE;

生成的是匿名事物，slave可以应用匿名和GTID事物

从库执行

等待从库
Retrieved_Gtid_Set
Executed_Gtid_Set
不再变动。
完成这一步实际上GTID事物已经没有生成和应用了

主库/从库执行

SET@@GLOBAL.GTID_MODE=OFF;

主库/从库执行

修改配置文件my.cnf，将参数的更改加入到配置文件