深入理解MySQL 5.7 GTID系列(十):实际案例二

简介: 1一、触发条件 本案列我测试过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有这个问题。
+关注继续查看

一、触发条件

本案列我测试过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有这个问题。其他版本未知

d47e62d2b349aca45e42305ed6714efbe5ed61d9已知percona Mysql 5.7.14或者官方社区 Mysql 5.7.17
d47e62d2b349aca45e42305ed6714efbe5ed61d9mysqldump备份没有使用 -F, --flush-logs选项

d47e62d2b349aca45e42305ed6714efbe5ed61d9Gtid打开

二、故障描述

本故障主要是新搭建的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可见的只有三个):

d47e62d2b349aca45e42305ed6714efbe5ed61d9mysql.gtid_executed表的写入
d47e62d2b349aca45e42305ed6714efbe5ed61d9gtid_executed变量的修改
d47e62d2b349aca45e42305ed6714efbe5ed61d9gtid_purged变量的修改

而完成了这一步实际上mysql.gtid_executed表是包含了全部的执行过的Gtid事务的,但是随后我们看到dump脚本包含了如下语句

680e58e44bf1e65b9606a0b25a223a4b0c28af6f

显然这里我们在source的时候从库的mysql.gtid_executed将被重新初始化为:

'e859a28b-b66d-11e7-8371-000c291f347d',1,32

而实际的已经执行过的Gtid是:

'e859a28b-b66d-11e7-8371-000c291f347d:1-41';

如前文第五节我们通过源码分析后总结如下:

mysql.gtid_executed表修改时机
在binlog发生切换(rotate)的时候保存直到上一个binlog文件执行过的全部Gtid,它不是实时更新的。

因此此时表中并没有完全包含全部执行过的Gtid事务,而在前文第六节的源码分析中我们知道在Gtid模块启动的时候必须要读取两个Gtid持久化的介质:

d47e62d2b349aca45e42305ed6714efbe5ed61d9mysql.gtid_executed
d47e62d2b349aca45e42305ed6714efbe5ed61d9binlog

来判断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表,让其正确。
此问题还可以在mysqldump的时候加入-F, --flush-logs选项规避,但是-F会加入如下的MDL LOCK:

e144c4ed18df9a7e76e0ff415239979b7cec3a47

这把锁是GLOBAL级别的MDL_SHARED(S)锁,它会等到你说有的SELECT/DML/DDL语句结束后才能获得,同时会堵塞全部的SELECT/DML/DDL虽然持有时间很短如下:

4def28888ccd2230b32057608ffb539ce65ebb8e

当然要了解MDL LOCK的朋友可以参考我的文章:
http://blog.itpub.net/7728585/viewspace-2143093/
MYSQL METADATA LOCK(MDL LOCK)学习(1) :理论知识和加锁类型测试
四、故障模拟

知道了原因后也是很好模拟我使用的版本是社区版5.7.17,搭建过程就是前面说的步骤。只是导完数据后不使用reset master和set gtid_purged表进行重新初始化mysql.gtid_executed表。搭建完成后做几个事务状态正常如下:

mysql> show slave status \G
*************************** 1. row ***************************
 Master_Log_File: binlog.000002
 Read_Master_Log_Pos: 5077
 Relay_Log_File: test1-relay-bin.000002
 Relay_Log_Pos: 2498
 Relay_Master_Log_File: binlog.000002
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
 Exec_Master_Log_Pos: 5077
 Relay_Log_Space: 2705
 Last_IO_Errno: 0
 Last_IO_Error: 
 Seconds_Behind_Master: 0
 Retrieved_Gtid_Set: e859a28b-b66d-11e7-8371-000c291f347d:42-49
 Executed_Gtid_Set: e859a28b-b66d-11e7-8371-000c291f347d:1-49
 Auto_Position: 1

但是这个时候我们发现mysql.gtid_executed表已经出现了问题如下:

00c47d7ad5cd85b53055bd0ab1c4ca11d91e38d4

很容易发现33-41之间是没有持久化的。如果这个时候如果我们使用purge binary logs to 来清理掉主库的日志那么必将出现问题,如果不清理也会出现Gtid事物重新执行的情况。我们做清理模拟线上错误。主库执行:

mysql> show binary logs;
+---------------+-----------+
| Log_name | File_size |
+---------------+-----------+
| binlog.000001 | 9974 |
| binlog.000002 | 5121 |
| binlog.000003 | 194 |
+---------------+-----------+
3 rows in set (0.01 sec)

mysql> purge binary logs to 'binlog.000003';
Query OK, 0 rows affected (0.04 sec)

mysql> show binary logs;
+---------------+-----------+
| Log_name | File_size |
+---------------+-----------+
| binlog.000003 | 194 |
+---------------+-----------+
1 row in set (0.00 sec)

备库重启后错误重现:

c900c6b79c9a8f2d2f05b3691f787c8785a0c558

我们发现I/O thread 试图获取主库的33-41的Gtid事务的事务,已经不能获取,实际上即使能获取也会造成事务的重新执行,我们看到Executed_Gtid_Set已经出现了两个连续的区间:

Executed_Gtid_Set: e859a28b-b66d-11e7-8371-000c291f347d:1-32:42-49

五、总结

前文已经描述过mysql.gtid_executed表的作用和其更改时机,如果我们对其有深刻的了解这个案例也是很容易分析的,当然解决办法在第八节主从搭建的步骤中我已经给出了,也就是在搭建完成后进行reset master和set global gtid_pruged两步重新初始化一下mysql.gtid_executed表。


原文发布时间为:2018-04-25

本文作者:高鹏(重庆八怪)

本文来自云栖社区合作伙伴“老叶茶馆”,了解相关信息可以关注“老叶茶馆”。

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
10月前
|
关系型数据库 MySQL
MySQL 基于 GTID 的组复制(MGR)
MySQL 基于 GTID 的组复制(MGR)
84 0
|
10月前
|
关系型数据库 MySQL
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
365 0
|
SQL 关系型数据库 MySQL
一个不规范操作导致MySQL主从同步中断(GTID模式)
一个不规范操作导致MySQL主从同步中断(GTID模式)
500 0
一个不规范操作导致MySQL主从同步中断(GTID模式)
|
关系型数据库 MySQL 数据库
基于GTID搭建主从MySQL
想让主从之间使用gtid的方式同步数据,需要我们在配置文件中开启mysql对gtid相关的配置信息 找到my.cnf ,在mysqld模块中加入如下的配置。(主库从库都这样)
121 0
|
关系型数据库 MySQL
|
关系型数据库 MySQL 数据库连接
MySQL一主多从复制(基于GTID)
宿主机环境下,运行多个MySQL,实现数据的主从复制
MySQL一主多从复制(基于GTID)
|
SQL 关系型数据库 MySQL
|
关系型数据库 MySQL 数据库
剖析MySQL GTID复制
今儿的这篇博文,可以让大家快速了解GTID特性,并能灵活地运用到生产环境中,希望对大家有帮助。GTID原理介绍GTID又叫全局事务ID(Global Transaction ID),是一个已提交事务的编号,并且是一个全局唯一的编号。
1190 0
|
运维 监控 关系型数据库
MySQL运维实战 之 价值一个亿的GTID监控
一、背景 现在的MySQL可谓是拿着望远镜也找不到对手,其中有一个非常大的特性就是GTID GTID的原理这篇文章不再展开,有兴趣的同学可以关注之前的GTID原理,GTID实战,GTID运维实战文章。
2663 0
|
存储 关系型数据库 MySQL
MySQL启用GTID的限制
开启 GTID 之后,会由部分的限制,内容如下: 更新非事务引擎表GTID 同步复制是基于事务的,所以 MyISAM 存储引擎不支持,这可能导致多个 GTID 分配给同一个事务。 使用GTID时,使用非事务性存储引擎(如MyISAM)对表的更新不能在与使用事务性存储引擎(如InnoDB)的表的更新相同的语句或事务中进行。
2710 0
推荐文章
更多
推荐镜像
更多