从MySQL 5.6开始增加了强大的Gtid（Global Transaction ID，全局事务ID）这个特性，用来强化数据库的主备一致性，故障恢复，以及容错能力。用于取代过去通过binlog文件偏移量定位复制位置的传统方式。借助GTID，在发生主备切换的情况下，MySQL的其它Slave可以自动在新主上找到正确的复制位置，这大大简化了复杂复制拓扑下集群的维护，也减少了人为设置复制位置发生误操作的风险。另外，基于GTID的复制可以忽略已经执行过的事务，减少了数据发生不一致的风险。
另外，我们熟知的MHA高可用方案在Gtid复制模式的切换下安全性更高了，还有MySQL 5.7.19发布的MGR（MySQL Group Replication）也同样是基于Gtid的，所以了解Gtid的原理也是必要的。
Gtid的维护是完全自动的，但是实际使用上确实有较多的坑，我的博客也写了一些Gtid相关的文章，但更多是基于应用层面，不够深入。下面这个Gtid系列文章是一个朋友@高鹏，网名@八怪，一个喜欢研究MySQL源码，喜欢分享，且乐于助人的80后码农。据说可是花了不少时间从Gtid模块的源码出发分析，并且给出总结，然后结合运维和案例进行综合的解析，你值得拥有。
MySQL 5.7 Gtid内部学习(二)：Gtid相关内部数据结构
MySQL 5.7 Gtid内部学习(三)：Gtid和Last_commt/sequnce_number的生成时机
MySQL 5.7 Gtid内部学习(四)：mysql.gtid_executed表的作用和Previous gtid Event的改变
MySQL 5.7 Gtid内部学习(五)：mysql.gtid_executed表/gtid_executed变量/gtid_purged变量的更改时机
MySQL 5.7 Gtid内部学习(六)：Mysql启动初始化Gtid模块
MySQL 5.7 Gtid内部学习(七)：总结binlog_gtid_simple_recovery参数带来的影响
MySQL 5.7 Gtid内部学习(八)：Gtid带来的运维改变
