GTID！MySQL复制中的核武器

各位老铁们，本周老张的《MySQL王者晋级之路》一书终于出版了，如今能够预购啦！
预购连接地址：老张的数据库微店
前先后后经历了一年的准备时间，可谓十年磨一剑，把本身从业全部的精华和心血都灌输到其书中。其书中包含了MySQL方方面面的知识点，是以前个人一篇博客“从青铜到王者，快速提高你MySQL数据库段位的全面深刻剖析”。用一句学生对我说得话，老师喜欢您的王者荣耀情怀，但更喜欢您的技术情操。讲真，不要错过！特别感谢在我从事技术道路上，帮助过个人前辈及兄弟们，这条路上的全部的辛酸，只有大家最懂我！也要感谢对我博客一直支持的兄弟们！

今儿的这篇博文，可让你们快速了解GTID特性，并能灵活地运用到生产环境中，但愿对你们有帮助。

GTID原理介绍
GTID又叫全局事务ID（Global Transaction ID），是一个已提交事务的编号，而且是一个全局惟一的编号。MySQL5.6版本以后在主从复制类型上新增了GTID复制。
GTID是由server_uuid和事务id组成的，即GTID = server_uuid:transaction_id。 server_uuid是在数据库启动过程当中自动生成的，每台机器的server-uuid不同。uuid存放在数据目录的auto.cnf文件下。而transaction_id就是事务提交时由系统顺序分配的一个不会重复的序列号。

GTID存在的价值
（1）GTID使用master_auto_position=1代替了基于binlog和position号的主从复制搭建方式，更便于主从复制的搭建。
（2）GTID能够知道事务在最开始是在哪一个实例上提交的。
（3）GTID方便实现主从之间的failover，不再用不断地去找position和binlog 了。

主从复制中GTID的管理与维护
GTID带来最方便的一点就是主从复制的搭建过程了。它跟异步复制、半同步复制相似，只不过再也不利用传统复制模式的binlog文件和position号了，而是在从库“change master to”时使用master_auto_position=1的方式进行搭建，这就让操做变得更加方便和可靠。

GTID搭建过程当中的注意事项
主从库须要设置的参数以下。
主库配置：

gtid_mode=on
enforce_gtid_consistency=on
log_bin=on

server-id不能与从库同样。

binlog_format=row

从库配置：

gtid_mode=on
enforce_gtid_consistency=on
log_slave_updates=1

虽然在MySQL5.7版本以后能够关闭掉log_slave_updates，使用gtid_executed这张表。但仍是建议在从库中开启。server-id不能与主库同样。
配置好参数以后，主库也建立了复制帐号，若是是新搭建的主从环境，就能够直接在从库就能够执行change master to语句了。若是是已经运行了一段期间的主库，还须要利用备份方式从主库“dump”出数据到从库中，先完成基于某个点的GTID复制，而后从库从那个点以后再开始追主库。利用mysqldump备份，备份后的文件中会有SET @@GLOBAL.GTID_PURGED= *，利用xtrabackup工具有份，备份后的文件中会直接记录须要跳过的GTID。启动复制以后，从库会直接跳过已经执行过GTID的范围，直接从主库获取新的GTID信息。
在主库执行show master status命令，经过Executed_Gtid_Set来查看执行过的GTID。

在MySQL5.7版本以后，gtid_executed这个值持久化了。在MySQL库下新增了一张表gtid_executed：

该表会记录已经执行的GTID集合的信息，有了这张表，就不用再像MySQL5.6版本时，必须开启log_slave_updates参数，从库才能够进行复制。GTID信息会保存在gtid_executed表中，能够关闭从库的binlog，节约binlog的记录开销。在执行reset master时，会清空表内全部的数据。
MySQL5.7还有一个参数gtid_executed_compression_period，用来控制gtid_executed表的压缩。该参数默认值为1000，意味着表压缩在执行完1000个事务以后开始。

从MySQL5.7.6开始，gtid_mode支持动态修改，gtid_mode可取值为：
OFF—不支持GTID的事务；
OFFPERMISSIVE—新的事务是匿名的，同时容许复制的事务能够是GTID，也能够是匿名的；
ON PERMISSIVE—新的事务使用GTID，同时容许复制的事务能够是GTID，也能够是匿名的；
ON—支持GTID的事务。
在生产环境中，可能有把传统复制改成GTID的复制模式的需求。这里特地强调一点，gtidmode虽然支持动态修改，但不支持跳跃式修改。从ON PERMISSIVE修改成OFF是不能够的。下面会有实验来展现传统复制与GTID复制之间的切换过程。
在从库上可经过show slave status命令来获取接收的gtid（retrieve_gtid_set）和执行的gtid（execute_gtid_set）。

GTID复制与传统复制的切换
前面已经搭建好了MySQL5.7版本的GTID复制模式，下面先来操做从GTID复制模式切换为传统复制模式的过程。
环境介绍：主库为192.168.56.101，从库为192.168.56.102。
当前主从状态展现。

实施过程以下：

（1）先在从库中执行stop slave，停掉主从复制。而后调整为传统复制模式，让master_auto_position=0。
执行以下命令：
CHANGE MASTER TO master_auto_position=0,Master_Host='192.168.56.101',MASTER_USER='bak',MASTER_PASSWORD='bak123','Master_Log_File='mysql-binlog.000002',MASTER_LOG_POS=1141;
执行完成以后，开启复制功能start slave。
（2）须要在主从服务器上同时调整GTID模式为on_permissive。

（3）须要在主从服务器上同时调整GTID模式为off_permissive。

（4）须要在主从服务器上同时关闭GTID功能。

（5）而后把gtid_mode=off和enforce_gtid_consistency=off写入配置文件my.cnf中。下次重启直接生效。
（6）测试是否切换成功。
首先向主库的zs库下的tt表中插入一条数据：

查看从库，这条数据同步成功。

而后在从库中执行show slave status查看主从复制状态，发现GTID的值没有增长，证实切换成功：

而后再操做从传统复制模式切换为GTID复制模式的过程。
实施过程以下：
（1）在主从库上同时修改参数enforce_gtid_consistency=warn，确保在error log中不会出现警告信息。若是有，须要先修复，才能日后继续执行。

（2）在主从服务器上把enforce_gtid_consistency改成on，保证GTID的一致性。

（3）在主从服务器上同时调整GTID模式为off_permissive。

（4）在主从服务器上同时调整GTID模式为on_permissive。

（5）确认从库的Ongoing_anonymous_transaction_count参数是否0，若是为0，意味着没有等待的事务，能够直接进行下一步操做了。

（6）在主从库上同时设置gtid_mode=on。

查看GTID参数设置，目前都是开启状态。

（7）把传统复制模式改成GTID复制。先要把原有的传统复制停掉，执行stop slave操做，而后再执行change master to master_auto_position=1。
执行完stop slave，查看当前主从的状态为：


而后再执行change master to master_auto_position=1，开启主从复制start slave。
（8）验证是否切换成功。
首先向主库的zs库下的tt表中插入一条数据：

查看从库，这条数据同步成功。

而后在从库中执行show slave status查看主从复制状态，发现GTID的值增长了。证实开启了GTID复制方式，切换成功。

GTID使用中的限制条件
GTID复制是针对事务来讲的，一个事务只对应一个GTID，好多的限制就在于此。
（1）不能使用create table table_name select * from table_name。
（2）在一个事务中既包含事务表的操做又包含非事务表。
（3）不支持CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE语句操做。
（4）使用GTID复制从库跳过错误时，不支持执行该sql_slave_skip_counter参数的语法。

感谢你们多多支持老张的新书，也感谢MySQL给咱们带来的最淳朴，最简单的快乐！

最后的最后