深入理解 MySQL 5.7 GTID 系列（一）

MySQL GTID 特性是5.6加入的一个强大的特性，它的目的在于使用 GTID 的 MySQL 能够在整个复制环境中能够自动地切换，而不像以前需要指定文件和位置，这也一定是未来发展的方向，我们熟知的 MGR 也是基于 GTID 的，所以了解 GTID 的原理也是必要的。

GTID 的维护是完全自动的，但是实际使用上确实有较多的坑，也导致很多朋友对GTID还是觉得畏惧，本系列文章将从 GTID 模块的源码出发分析，并且给出总结，然后结合运维和案例进行综合的解析，我希望抛砖引玉让希望了解源码的朋友也有所收获，但是能力有限特别是源码部分如果有错误请指出，并且能够一起交流，如果有朋友有更好的案例也欢迎一起探讨。 当然留下这么一个系列也有自己的原因，好记性不如烂笔头嘛，因此也当自己的一个笔记了。

GTID 事务的生命周期

GTID 的全称为 global transaction identifier，他在整个复制生态中完全唯一的，下面我们通过一个图来解释它的整个生命周期，假设我们这里有一个 master->slave->slave 的复制环境，生成了一个 GTID 为 89dfa8a4-cb13-11e6-b504-000c29a879a3:1 的 GTID 事务，因为名字太长我简化为 879a3:1 如图：

我们可以看到在整个生命周期中整个事务的 GTID 号是没有改变的，不管在主库还是从库它都是 89dfa8a4-cb13-11e6-b504-000c29a879a3:1，这也是为什么叫做全局的原因。

本节只是一个导读，希望能够让大家对 GTID 有一个基本了解，如果需要继续了解可以看看官方文档。