mysql binlog gtid_binlog的GTID模式基础及基于GITD的数据恢复

本文中的mysql版本：5.7.26

前言

gtid功能是mysql5.6版本开始新加入的特性，在5.7、8.0及以上版本中做了加强，特别是从mysql8.0版本开始，应该是主推基于gtid模式的复制了。通过gtid保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性，故障恢复以及容错能力。虽说gtid是mysql5.6加入的特性，但是在5.6版本中并不支持该功能，也就是说mysql5.6版本中无法开启该功能。5.7版本中 即使没有开启gtid，默认也会以匿名的方式记录gtid，匿名的方式记录的gtid是由系统进行管理和维护的，我们是无法使用的。所以 如果要搭建mysql主从复制模式，并且是基于gtid模式进行复制的话，mysql版本最低是5.7的版本。

在传统的mysql基于二进制日志的模式复制中，从库需要告知主库 要从哪个二进制日志文件中的那个偏移量进行增量同步，如果指定错误会造成数据的遗漏，从而造成数据的不一致。借助gtid，在发生主备切换的情况下，mysql的其它从库可以自动在新主库上找到正确的复制位置，这大大简化了复杂复制拓扑下集群的维护，也减少了人为设置复制位置发生误操作的风险。另外，基于gtid的复制可以忽略已经执行过的事务，减少了数据发生不一致的风险。所以说，相比mysql传统的主从复制模式，gtid模式的复制对于 DBA/开发人员/运维 等相关技术人员更加友好。实际上 gtid这个功能 主要是为了主从复制而来的，gtid是为了代替mysql传统的主从复制模式(通过某一个binlog二进制日志文件中的pos位置偏移量等相关信息 来进行复制)。当然了，gtid在单机状态下 作用不是很大，它主要还是为了主从而来的。

可能大多数人第一次听到gtid的时候会感觉有些突兀，但是从架构设计的角度，gtid是一种很好的分布式ID实践方式，通常来说，分布式ID有两个基本要求：

①、全局唯一性

②、趋势递增

这个ID因为是全局唯一，所以在分布式环境中很容易识别，因为趋势递增，所以ID是具有相应的趋势规律，在必要的时候方便进行顺序提取。所以换一个角度来理解gtid，其实是一种优雅的分布式设计。

GTID的基本概念和组成(Global Transaction ID)

GTID (Global Transaction ID) 是对于一个已提交事务的编号，并且是一个全局唯一的编号。 GTID实际上是由server_uuid+transaction_id组成的。

server_uuid：是一个mysql实例的唯一标识，每一台mysql实例的server_uuid都是不同的，在mysql第一次启动时，会自动生成并持久化到auto.cnf文件(存放在mysql的数据目录下，这是一个非常重要的文件，不能删除，这一部分是不会变的)，也可以在mysql中执行select @@server_uuid;命令查看当前mysql实例的server_uuid，显示的结果就是auto.cnf文件中保存的server_uuid。

transaction_id：代表了该实例上已经提交的事务数量，transact