剖析MySQL GTID复制

今儿的这篇博文，可以让大家快速了解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=onenforce_gtid_consistency=onlog_bin=on

server-id不能与从库一样。
从库配置：

binlog_format=rowgtid_mode=onenforce_gtid_consistency=onlog_sla ve_updates=1

虽然从MySQL 5.7开始，已经可以通过关闭log_sla ve_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 集合信息记下来。这样一来，就不必再像 MySQL 5.6 那样，非得开启 log_sla ve_updates 参数，从库才能继续复制。GTID 相关信息会落到 gtid_executed 表里，因此从库的 binlog 可以直接关闭，从而省掉一部分 binlog 记录带来的开销。需要注意的是，一旦执行 reset master，这张表里的数据也会被全部清空。
在 MySQL 5.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 sla ve status命令来获取接收的gtid（retrieve_gtid_set）和执行的gtid（execute_gtid_set）。

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

实施过程如下：

（1）先在从库中执行stop sla ve，停掉主从复制。然后调整为传统复制模式，让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 sla ve。
（2）需要在主从服务器上同时调整GTID模式为on_permissive。

需要在主从服务器上同时调整gtid模式为off_permissive;
需要在主从服务器上同时关闭gtid功能；
然后记得把修改gtid_mode=off和enforce_gtid_consistency=off写入配置文件my.cnf中。下次重启直接生效。测试是否切换成功。
首先向主库的zs库下的tt表中，插入一条数据

查看从库，正常把这条数据同步成功！

然后在从库执行show sla ve status查看主从复制状态，发现gtid的值没有增加。证明切换成功

然后再操作从传统复制模式切换为GTID复制模式的过程;
实施过程如下：
1.先要在主从库上同时修改参数enforce_gtid_consistency=warn。确保在error log中不会出现警告信息。如果有，需要先修复，才能往后进行执行。

2.然后再在主从服务器上把enforce_gtid_consistency改为on，来保证gtid的一致性

接着在主从服务器上同时调整gtid模式为off_permissive;
继续在主从服务器上同时调整gtid模式为on_permissive;
确认从库的Ongoing_anonymous_transaction_count该参数是否0，如果为0，意味着没有等待的事务。可以直接进入下一步操作了！
在主从库上同时设置gtid_mode=on

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

最后一步把传统复制模式改为gtid复制。先要把原有的传统复制停掉，执行stop sla ve操作，然后再执行change master to master_auto_position=1;
执行完stop sla ve查看当前主从的状态为：

然后再执行change master to master_auto_position=1;随之开启主从复制start sla ve;

验证是否切换成功
首先向主库的zs库下的tt表中，插入一条数据

查看从库，正常把这条数据同步成功！

然后在从库执行show sla ve 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_sla ve_skip_counter参数的语法。