Mysql 5.7 Gtid内部实际案例解析
发布时间：2021-12-20 20:24:59 所属栏目：MySql教程 来源：互联网
导读：本篇内容介绍了Mysql 5.7 Gtid内部实际案例分析的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！ 一、触发条件 本案列我测试过4个版本 percona Mysql
|
本篇内容介绍了“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表，让其正确。 （编辑：云计算网_泰州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330476号