本篇内容介绍了“Mysql 5.7 Gtid内部实际案例分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
 
一、触发条件
本案列我测试过4个版本
percona Mysql 5.7.14
官方社区 Mysql 5.7.17
percona Mysql 5.7.19
percona Mysql 5.7.15
其中percona Mysql 5.7.14和官方社区 Mysql 5.7.17有这个问题。其他版本未知
 
已知percona Mysql 5.7.14或者官方社区 Mysql 5.7.17。
mysqldump备份没有使用 -F, –flush-logs选项
Gtid打开。
二、故障描述
本故障主要是新搭建的Gtid主从库，运行一段时间后重启主从必然报错如下：
 
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
三、故障分析
为什么重启后会报错找到不事物呢，然后发现这个Gtid事物在主库的binlog中已经没有了，应该是很久以前的。其实这个问题我们要回到mysqldump出来的文件如何进行Gtid的初始化以及mysql.gtid_executed表中。
在mysqldump不使用–set-gtid-purged的时候必然会在dump出来的脚本中包含
 
— GTID state at the beginning of the backup
 SET @@GLOBAL.GTID_PURGED='e859a28b-b66d-11e7-8371-000c291f347d:1-41';
这样一个设置GTID_PURGED的语句，它包含了主库上已经执行的全部Gtid事物。从第五节的源码和总结部分我们知道这个语句至少做了三个更改(DBA可见的只有三个)：
 
mysql.gtid_executed表的写入
gtid_executed变量的修改
gtid_purged变量的修改
而完成了这一步实际上mysql.gtid_executed表是包含了全部的执行过的Gtid事物的，但是随后我们看到dump脚本包含了如下语句
 
 210  — Table structure for table `gtid_executed`
   211  —
   212
   213  DROP TABLE IF EXISTS `gtid_executed`;
   214  /*!40101 SET @saved_cs_client     = @@character_set_client */;
   215  /*!40101 SET character_set_client = utf8 */;
   216  CREATE TABLE `gtid_executed` (
   217    `source_uuid` char(36) NOT NULL COMMENT 'uuid of the source where the transaction was originally executed.',
   218    `interval_start` bigint(20) NOT NULL COMMENT 'First number of interval.',
   219    `interval_end` bigint(20) NOT NULL COMMENT 'Last number of interval.',
   220    PRIMARY KEY (`source_uuid`,`interval_start`)
   221  ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
   222  /*!40101 SET character_set_client = @saved_cs_client */;
   223
   224  —
   225  — Dumping data for table `gtid_executed`
   226  —
   227
   228  LOCK TABLES `gtid_executed` WRITE;
   229  /*!40000 ALTER TABLE `gtid_executed` DISABLE KEYS */;
   230  INSERT INTO `gtid_executed` VALUES ('e859a28b-b66d-11e7-8371-000c291f347d',1,32);
   231  /*!40000 ALTER TABLE `gtid_executed` ENABLE KEYS */;
   232  UNLOCK TABLES;
显然这里我们在source的时候从库的mysql.gtid_executed将被重新初始化为：
 
mysql.gtid_executed
binlog
来判断Gtid的集合，显然从库不可能在binlog包含这个Gtid事物，所以这样的操作步骤就导致了数据库从库后的报错，而这里的正确的步骤是压根不进行mysql.gtid_executed的重建和导入，我发现在percona Mysql 5.7.15和percona Mysql 5.7.19正是这样的。但是为了防范这个问题，我在搭建的Gtid从库导完数据后加入了两个个步骤如下：
 
reset master；
set global gtid_purged='e859a28b-b66d-11e7-8371-000c291f347d:1-41';
这两步也就是为了从新初始化mysql.gtid_executed表，让其正确。