MySQL GTID Replication：

从MySQL5.6开始增加了强大的GTID（Global Transaction ID，全局事务ID）这个特性，用来强化数据库的主备一致性， 故障恢复， 以及容错能力。用于取代过去传统的主从复制（即：基于binlog和position的异步复制）。

借助GTID，在发生主备切换的情况下，MySQL的其他slave可以自动在新主上找到正确的复制位置，这大大简化了复杂复制拓扑下集群的维护，也减少了人为设置复制position发生误操作的风险。另外，基于GTID的复制可以忽略已经执行过的事务，减少了数据发生不一致的风险。


GTID组成：

GTID是由server_uuid和事务id组成的，即GTID=server_uuid:transaction_id。
server_uuid，是在MySQL第一次启动时自动生成并持久化到auto.cnf文件（存放在数据目录下，每台机器的server_uuid都不一样。
transaction_id，是一个从1开始的自增计数，表示在这个主库上执行的第n个事务。MySQL会保证事务与GTID之间的1:1映射，如：b6af5b5c-666f-11e9-bed3-000c29b85ea6:1
表示在以b6af5b5c-666f-11e9-bed3-000c29b85ea6为唯一标识的MySQL实例上执行的第1个数据库事务。
一组连续的事务可以用 "-" 连接的事务序号范围表示。例如：b6af5b5c-666f-11e9-bed3-000c29b85ea6:1-5


基于GTID复制的优点：

1、根据传统的复制原理，当连接发生故障时，需要重新连接到master主机，需要找到binlog和position，然后change master to 连接到master主机，此过程需要人工来做，比较麻烦，也容易出错，尤其是master写操作较多时，更不容易确定position，如果flush table with read lock，势必会影响到线上业务。而GTID复制方式不需要找master的binlog和position，只需要知道master的ip、端口、账号密码，即可进行复制，MySQl会通过内部机制自动找点同步（MASTER_AUTO_POSITION=1）
简单来说就是：简化复制。传统复制是基于file和position来实现的，而file和position是人为确定的，file还好一些，但是position却是实时变动的，难以确定，除非对全库加读锁，但这势必会对线上业务产生影响，GTID会自动找position进行数据同步


2、多线程复制（基于库），在MySQL5.6以前的版本，slave的复制是单线程的。一个事件一个事件的读取应用。而master是并发写入的，所以延迟是避免不了的。唯一有效的方法是把多个库放在多台slave，这样又有点浪费服务器。在MySQL5.6里面，我们可以把多个表放在多个库，这样就可以使用多线程复制，当只有1个库，多线程复制是没有用的（即：所谓的并行复制）
简单来说就是：跟多线程复制相关。多线程复制是基于组提交方式实现的，而组提交信息是存储在GTID中的


GTID的作用：

1、根据GTID可以知道事务最初是在哪个实例上提交的
2、GTID的存在方便了Replication的Failover


GTID复制实现的工作原理：
1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中
2、slave端的I/O线程将变更的binlog，写入到本地的relay log中
3、SQL线程从relay log中获取GTID，然后对比slave端的binlog是否有记录（所以MySQL5.6 slave端必须开启binlog）
4、如果有记录，说明该GTID的事务已经执行，slave会忽略
5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog
6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描


GTID使用限制：
1、  MySQL5.7之后才开始支持动态切换GTID相关的参数
2、  不支持CREATE TABLE ... SELECT statements
3、  不支持CREATE TEMPORARY TABLE statements inside transactions
4、  transaction or statement 既更新了事务表又更新了非事务表
5、  使用GTID复制从库跳过错误时，不支持执行sql_slave_skip_counter参数的语法


GTID相关状态变量介绍：
推荐阅读MySQL官网英文原著

Master、Slave上都可以查看GTID相关的状态变量
mysql> show global variables like '%gtid%';
+--------------------------+------------------------------------------+
| Variable_name            | Value                                    |
+--------------------------+------------------------------------------+
| enforce_gtid_consistency | ON                                       |
| gtid_executed            | b6af5b5c-666f-11e9-bed3-000c29b85ea6:1-7 |
| gtid_mode                | ON                                       |
| gtid_owned               |                                          |
| gtid_purged              |                                          |
+--------------------------+------------------------------------------+
5 rows in set (0.00 sec)


以下内容是笔者从博客、论坛等收集的资料，不保证正确性，仅供参考：

1、gtid_executed
在当前实例上执行过的GTID集合，实际上包含了所有记录到binlog中的事务。所以，设置set sql_log_bin=0后执行的事务不会生成binlog事件，也不会被记录到gtid_executed中。执行reset master可以将该变量清空

2、gtid_purged
binlog不可能永久停留在服务器上，需要进行定期清理（如通过expire_logs_days），否则迟早它会把磁盘空间用完。gtid_purged用于记录已经被清除了的binlog事务集合，它是gtid_executed的子集。只有gtid_executed为空时才能手动设置该变量，此时会同时更新gtid_executed为和gtid_purged相同的值。gtid_executed为空意味着要么之前没有启动过基于GTID的复制，要么执行过reset master。执行reset master时同样也会把gtid_purged置空，即始终保持gtid_purged是gtid_executed的子集。

3、gtid_next
会话级变量，指示如何产生下一个GTID。可能的取值：
AUTOMATIC，自动生成下一个GTID，实现上是分配一个当前实例上尚未执行过的序号最小的GTID
ANONYMOUS，设置后执行事务不会产生GTID
显式指定的GTID，可以指定任意形式合法的GTID值，但不能是当前gtid_executed中的已经包含的GTID，否则，下次执行事务时会报错

4、gtid_mode
是否开启GTID复制功能

5、enforce-gtid-consistency = ON
启动强制GTID的一致性，如果开启GTID功能则此参数必须要开启；slave在做同步复制时，无须找到binlog日志和POS点，直接change master to master_auto_position=1即可，自动根据GTID进行同步数据。


延伸：

多线程复制：

MySQL5.6之前的版本，同步复制是单线程的、队列的，只能一个一个执行。在MySQL5.6里，可以做到多个库之间的多线程复制。例如数据库里，存放着用户表、商品表、价格表、订单表，那么将每个业务表单独放在一个库里，这时就可以做到多线程复制，但一个库里的表，多线程复制是无效的（因为同一个库进行多线程复制到Slave上时会造成问题）；每个数据库仅能使用一个线程（即：MySQL5.6多线程复制基于库），复制涉及到多个数据库时多线程复制才有意义。Slave上多线程复制的控制参数为slave-parallel-workers=0（0表示禁用多线程功能）


题外：

本文的主要作用是记录GTID的用途、优缺点、使用限制、状态变量介绍等，内容大多是从MySQL官网或者一些博客论坛摘录的理解。本着实践是检验真理的唯一标准的原则，记录本文更多的作用为将来实际应用的时候做铺路。所以，笔者不保证内容准确性，仅供参考。欢迎业内大佬指出其中不当之处，在此先表示感谢！