Mysql 5.7 Gtid内部学习(八) Gtid带来的运维改变

依托前文的解析来讲5.7中 Gtid带来的运维改变，我想理解应该是更加深刻，这节主要讨论以下几个部分：

如何跳过一个事务

mysqldump导出行为的改变

5.7中搭建基于Gtid的主从

5.7中Gtid的主从的切换

5.7中在线改变Gtid模式

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

show slave status \G 中的 Executed_Gtid_Set。

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

show master status;中的Executed_Gtid_Set。

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

如果是多个如下：

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

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

为什么要这么设置呢？因为如果做基于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。下面是这个选项的含义。

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

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

同时主备库都开启binlog如果不设置级联从库，从库不要设置log_slave_updates参数。

这是最合理的设置。

建立复制用户

导出数据

从库导入数据

source即可。

从库执行reset master语句

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

提取GTID_PURGED，并且执行

使用head -n 40 命令可以快速的得到比如我这里的

执行

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

使用MASTER_AUTO_POSITION建立同步

启动slave

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

从库(新主库)

主库(新从库)

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

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

这样也是不会增加本地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)。

主库/从库执行

确定事务都支持gtid，不会在err log中出现警告如下：

2017-02-26T22:35:24.322055Z 55 [Warning] Statement violates GTID consistency: CREATE TABLE ... SELECT.

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

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

确定已经没有匿名的事务

同时确认从库

Retrieved_Gtid_Set

Executed_Gtid_Set

正常增长

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

从库执行

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

记录从库执行状态值

等待从库

不再变动。

完成这一步实际上GTID事务已经没有生成和应用了

学习完本节至少能够学习到：

5.7中在线改变Gtid 模式

关于其他运维可以参考官方文档：

Chapter 18 Replication