本篇内容主要讲解“Mysql 5.7中Gtid带来的运维改变分析”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Mysql 5.7中Gtid带来的运维改变分析”吧!
一、如何跳过一个事物
和传统基于位置的主从不同，如果从库报错我们需要获得从库执行的最后一个事物，方法有如下：
show slave status \G 中的 Executed_Gtid_Set。
show global variables like '%gtid%'; 中的 gtid_executed 。
show master status;中的Executed_Gtid_Set。
然后构建一个空事物如下：
stop slave ;
set gtid_next='4a6f2a67-5d87-11e6-a6bd-000c29a879a3:34';
begin;commit;
set gtid_next='automatic';
start slave ;
如果是多个如下：
stop slave ;
set gtid_next='89dfa8a4-cb13-11e6-b504-000c29a879a3:3';
begin;commit;
set gtid_next='89dfa8a4-cb13-11e6-b504-000c29a879a3:4';
begin;commit;
set gtid_next='automatic';
start slave ;
二、 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;
—
— GTID state at the beginning of the backup
—
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' to the output. Possible
values for this option are ON, OFF and AUTO. If ON is
used and GTIDs are not enabled on the server, an error is
generated. If OFF is used, this option does nothing. If
AUTO is used and GTIDs are enabled on the server, 'SET
@@GLOBAL.GTID_PURGED' is added to the output. If GTIDs
are disabled, AUTO does nothing. If no value is supplied
then the default (AUTO) value will be considered.
三、5.7中搭建基于Gtid的主从
这里存在一个注意点，也是我案例中会提到的。我们还是直接说步骤
建立复制用户
CREATE USER 'repl'@'%' IDENTIFIED BY 'test123';
GRANT REPLICATION SLAVE ON *.* 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又不存在。所以为了安全还是执行下面的两步。
reset master；
提取GTID_PURGED，并且执行
使用head -n 40 命令可以快速的得到比如我这里的
—
— GTID state at the beginning of the backup
—
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表会重构。
