mysql gtid复制原理_GTID复制的工作原理

笔记说明：

本文翻译自官网，当然会根据语义做一些解释或总结简化，有些地方为了理解顺畅也有删减，有些地方直接翻为中文略显生硬，如有疑问请直接参考上述链接中的原文。

本文主要介绍GTID的生成方式、基于GTID的主从同步时的工作机制，对于如何搭建GTID主从复制以及GTID主从复制为何可以实现并行复制的原理未做详细介绍，后者原理可以参考innodb二阶段日志提交机制和组提交解析理解。

基于GTID的主从同步在出现问题时，除了手动的重新开启下同步进程你能做的操作很少，相比之下原始的基于binlog pos的复制比较灵活，为了避免这种情况发生有必要探究一下基于GTID复制的工作机制，以便在主从同步异常时有效的进行修复。

本文的主要目的就是搞清GTID的生成和使用机制，搞清基于GTID复制的主要流程和核心参数，保证在GTID复制出现问题时可以通过灵活的处理相关参数来拯救主从复制。

一、GTID的生命周期如下：

1. 当事务于主库执行时，系统会为事务分配一个由server uuid加序列号组成的GTID(当然读事务或者被主动过滤掉的事务不会被分配GTID)，写binlog日志时此GTID标志着一个事务的开始。GTID的格式如下所示：

GTID = source_id:transaction_id

# source_id为server的uuid

# transaction_id是一个表示事务执行顺序的序列号，例如第一个执行的事务transaction_id为1，第10个为10

# GTID = :1-10表示从1-10的10个事务的集合，称作gtid set

2. binlog中写GTID的event被称作Gtid_log_event，当binlog切换或者mysql服务关闭时，之前binlog中的所有gtid都会被加入mysql.gtid_executed表中。此表内容如下(slave中此表记录数会有多条，取决于主从个数)：

mysql> select * from mysql.gtid_executed;

+--------------------------------------+----------------+--------------+

| source_uuid | interval_start | interval_end |

+--------------------------------------+----------------+--------------+

| 71cf4b9d-8343-11e8-97f1-a0d3c1f25190 | 1 | 653948549 |

+--------------------------------------+----------------+--------------+

3. 当GTID被分配且事务被提交后，他会被迅速的以一种外部的、非原子性的方式加入@@GLOBAL.gtid_executed参数中，这个参数包含了所有被提交的GTID事务(其实他是一个GTID范围值，例如71cf4b9d-