开发者社区> 技术小能手> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

深入理解MySQL 5.7 GTID系列(四):mysql.gtid_executed&PREVIOUS GTID EVENT

简介: 之所以把MySQL.GTID_EXECUTED表的作用和PREVIOUS GTID EVENT的改变放到一起进行描述是因为它们后面文章探讨的基础。这部分使用到了我自己使用C语言写的原生BINLOG解析工具INFOBIN。
+关注继续查看

之所以把MySQL.GTID_EXECUTED表的作用和PREVIOUS GTID EVENT的改变放到一起进行描述是因为它们后面文章探讨的基础。这部分使用到了我自己使用C语言写的原生BINLOG解析工具INFOBIN。
百度云盘下载如下:http://pan.baidu.com/s/1jHIWUN0

一、GTID EVENT
为什么要先描述什么是GTID EVENT呢?因为后面会用到,实际上在其中核心元素就是一个形如:

31704d8a-da74-11e7-b6bf-52540a7d243:100009

的一个GTID 处于整个事务EVENT中的开始,用于描述这个事务的GTID 是多少,当然在5.7中为了支持MTS其中还封装了LAST_COMMIT/SEQUENCE_NUMBER。那么使用INFOBIN工具查看一个INSERT单条语句完整事务的EVENT包括如下:

>Gtid Event:Pos:234(0Xea) N_pos:299(0X12b) Time:1513135186 Event_size:65(bytes) 
Gtid:31704d8a-da74-11e7-b6bf-52540a7d243:100009 last_committed=0  sequence_number=1
-->Query Event:Pos:299(0X12b) N_Pos:371(0X173) Time:1513135186 Event_size:72(bytes) 
Exe_time:0  Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:100009
---->Map Event:Pos371(0X173) N_pos:415(0X19f) Time:1513135186 Event_size:44(bytes) 
TABLE_ID:108 DB_NAME:test TABLE_NAME:a Gno:100009
------>Insert Event:Pos:415(0X19f) N_pos:455(0X1c7) Time:1513135186 Event_size:40(bytes) 
Dml on table: test.a  table_id:108 Gno:100009 
>Xid Event:Pos:455(0X1c7) N_Pos:486(0X1e6) Time:1513135186 Event_size:31(bytes) 
COMMIT; /*!Trx end*/ Gno:100009

当然也可以使用MySQLBINLOG进行分析,只是格式稍微不那么友好。

二、GTID_EXECUTED表的作用
这一部分是重点中的重点,也是我以前一直疑惑的,请大家细细品读。
官方文档这样描述GTID_EXECUTED

Beginning with MySQL 5.7.5, GTIDs are stored in a table named gtid_executed, in the mysql
database. A row in this table contains, for each GTID or set of GTIDs that it represents, the UUID of the
originating server, and the starting and ending transaction IDs of the set; for a row referencing only a
single GTID, these last two values are the same.

也就是说GTID_EXECUTED表是GTID持久化的一个工具,如前文所描述GTID_STATE中的
GET_EXECUTED_GTIDS/GET_LOST_GTIDS/GET_GTIDS_ONLY_IN_TABLE/GET_PREVIOUS_GTIDS_LOGGED这些数据都是存储在内存中的,那么在数据库重启后需要进行初始化,那么这需要读取GTID持久化的介质,我们可以发现GTID_EXECUTED是一个
INNODB表建表语句如下,并且我们可以手动更改它,但是千万不要这么干:

Table: gtid_executed
Create Table: CREATE TABLE `gtid_executed` (
  `source_uuid` char(36) NOT NULL COMMENT 'uuid of the source where the transaction was originally executed.',
  `interval_start` bigint(20) NOT NULL COMMENT 'First number of interval.',
  `interval_end` bigint(20) NOT NULL COMMENT 'Last number of interval.',
  PRIMARY KEY (`source_uuid`,`interval_start`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 STATS_PERSISTENT=0

那么在5.7.5以前没有GTID_EXECUTED表不是也没有问题吗?其实除了GTID_EXECUTED表以外我们还有一个GTID持久化的介质那就是BINLOG中的GTID EVENT。所以总结一下GTID持久化介质:

GTID_EXECUTED表

BINLOG中的GTID  EVENT

那么既然有了BINLOGGTID EVENT进行持久化那么为什么还需要GTID_EXECUTED表呢?这实际上就是5.7.5过后的一个优化,我们可以反过来思考在5.6中如果使用了GTID 做从库,从库如果不开启BINLOG并且同时设置LOG_SLAVE_UPDATES=TURE那么从库的执行过的GTID事务是没有办法持久化的。我们来一段5.6官方文档对于搭建GTID从库的其中一步:

Step 3: Restart both servers with GTIDs enabled. To enable binary logging with global
transaction identifiers, each server must be started with GTID mode, binary logging, slave update
logging enabled, and with statements that are unsafe for GTID-based replication disabled. In addition,
you should prevent unwanted or accidental updates from being performed on either server by starting
both in read-only mode. This means that both servers must be started with (at least) the options shown
in the following invocation of mysqld_safe:
shell> mysqld_safe --gtid_mode=ON --log-bin --log-slave-updates --enforce-gtid-consistency &

开启BINLOG同时设置设置LOG_SLAVE_UPDATES=TURE必然造成一个问题,实际上从库很多时候我们是不需要做级联SLAVE,设置LOG_SLAVE_UPDATES=TURE会造成需要额外的空间和性能开销。自然这种情况下我们需要另外的一种GTID持久化介质,而并不是BINLOG中的GTID EVENT。为了解决这个问题,5.7中GTID_EXECUTED表应运而生了。然而GTID_EXECUTED表是否需要实时更新呢?显然在slave端不开启BINLOG或者开启BINLOG不设置LOG_SLAVE_UPDATES=TURE的情况下它需要实时更新,因为I/O THREAD执行过得GTID是必须持久化的,而在主库上因为有BINLOG的GTID EVENT的存在他是不需要实时更新的,这样不同的对待方式也能够减轻负担提高性能。
同时在官方文档上也有相关描述它分为是否开始BINLOG进行描述,但是其描述并不是最详细的。所以这部分在后面我会进行详细描述。

三、PREVIOUS GTID EVENT的改变
PREVIOUS GTID EVENT是包含在每一个BINLOG的开头用于描述所有以前BINLOG所包含的全部GTID的一个集合(包括已经删除的BINLOG)如:

da267088-9c22-11e7-ab56-5254008768e3:1-32

在5.6中如果不开启GTID,那么BINLOG是不会包含这个PREVIOUS GTID EVENT的,但是在5.7中不开启GTID也会包含这个PREVIOUS GTID EVENT,实际这一点的改变其意义也是非常巨大,简单的说他为快速扫描BINLOG(BINLOG_GTID_SIMPLE_RECOVERY=TURE)获得正确GTID集合提供了基础,否则将会扫描大量的BINLOG,从而浪费I/O性能,这是5.6中一个非常严重的问题,在5.7的官方文档这样描述:

When binlog_gtid_simple_recovery=TRUE, which is the default in MySQL 5.7.7 and
later, the server iterates only the oldest and the newest binary log files and the values of
gtid_purged and gtid_executed are computed based only on Previous_gtids_log_event
or Gtid_log_event found in these files. This ensures only two binary log files are iterated during
server restart or when binary logs are being purged

当然这部分也会在后面进行详细的描述,这里只是简单提一下。那么我们通过MySQLBINLOG 和INFOBIN工具分别确认这一点。

  • 5.6. 26 不开启GTID

MySQLBINLOG:

*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#171211 16:20:10 server id 20155  end_log_pos 120 CRC32 0x12617db7      Start: binlog v 4, server v 5.6.26-74.0-log created 171211 16:20:10
# Warning: this binlog is either in use or was not closed properly.
# at 120
#171211 16:20:14 server id 20155  end_log_pos 192 CRC32 0x696752cb      Query   thread_id=30

INFOBIN:

------------Detail now--------------
>Format description log Event:Pos:4(0X4) N_pos:120(0X78) Time:1512980410 Event_size:116(bytes) 
-->Query Event:Pos:120(0X78) N_Pos:192(0Xc0) Time:1512980414 Event_size:72(bytes) 
Exe_time:0  Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:0
---->Map Event:Pos192(0Xc0) N_pos:241(0Xf1) Time:1512980414 Event_size:49(bytes) 
TABLE_ID:91 DB_NAME:test TABLE_NAME:testpo Gno:0
------>Insert Event:Pos:241(0Xf1) N_pos:281(0X119) Time:1512980414 Event_size:40(bytes) 
Dml on table: test.testpo  table_id:91 Gno:0 
>Xid Event:Pos:281(0X119) N_Pos:312(0X138) Time:1512980414 Event_size:31(bytes) 
COMMIT; /*!Trx end*/ Gno:0

我们并没有发现PREVIOUS GTID EVENT,也就是5.6如果不开启GTID则不包含PREVIOUS GTID EVENT

  • 5.7.14

MySQLBINLOG:

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#171211 16:26:49 server id 1  end_log_pos 123 CRC32 0xf9a36298  Start: binlog v 4, server v 5.7.14-7-debug-log created 171211 16:26:49
# Warning: this binlog is either in use or was not closed properly.
# at 123
#171211 16:26:49 server id 1  end_log_pos 194 CRC32 0x5865633f  **Previous-GTIDs**
# da267088-9c22-11e7-ab56-5254008768e3:1-32
# at 194

INFOBIN:

------------Detail now--------------
>Format description log Event:Pos:4(0X4) N_pos:123(0X7b) Time:1512980809 Event_size:119(bytes) 
>Previous gtid Event:Pos:123(0X7b) N_pos:194(0Xc2) Time:1512980809 Event_size:71(bytes) 
>Anonymous gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1512980814 Event_size:65(bytes) 
Gtid:Anonymous(Gno=0) last_committed=0  sequence_number=1
-->Query Event:Pos:259(0X103) N_Pos:331(0X14b) Time:1512980814 Event_size:72(bytes) 
Exe_time:0  Use_db:test Statment(35b-trun):BEGIN /*!Trx begin!*/ Gno:0
---->Map Event:Pos331(0X14b) N_pos:380(0X17c) Time:1512980814 Event_size:49(bytes) 
TABLE_ID:154 DB_NAME:test TABLE_NAME:testpo Gno:0
------>Insert Event:Pos:380(0X17c) N_pos:420(0X1a4) Time:1512980814 Event_size:40(bytes) 
Dml on table: test.testpo  table_id:154 Gno:0 
>Xid Event:Pos:420(0X1a4) N_Pos:451(0X1c3) Time:1512980814 Event_size:31(bytes) 
COMMIT; /*!Trx end*/ Gno:0

我们清晰的看到这里包含了PREVIOUS GTID EVENT,当然我们还发现了ANONYMOUS GTID EVENT这也是5.7中变化,5.7中即使不开始GTID每个事务也包含也一个ANONYMOUS GTID EVENT,虽然没有GTID但是它任然包含了LAST_COMMITTED/SEQUENCE_NUMBER

四、本节小结
学习完本节至少能够学习到:

  • 1、什么是GTID EVENT。包含什么重要元素。
  • 2、为什么需要GTID_EXECUTED表及其作用。
  • 3、5.7中PREVIOUS GTID EVENT发生了哪些改变。
  • 4、简单了解PREVIOUS GTID EVENT的改变意味着什么。

原文发布时间为:2018-01-17
本文作者:高鹏(重庆八怪)
本文来自云栖社区合作伙伴“老叶茶馆”,了解相关信息可以关注“老叶茶馆”微信公众号

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
MySQL 基于 GTID 的组复制(MGR)
MySQL 基于 GTID 的组复制(MGR)
0 0
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
0 0
一个不规范操作导致MySQL主从同步中断(GTID模式)
一个不规范操作导致MySQL主从同步中断(GTID模式)
0 0
基于GTID搭建主从MySQL
想让主从之间使用gtid的方式同步数据,需要我们在配置文件中开启mysql对gtid相关的配置信息 找到my.cnf ,在mysqld模块中加入如下的配置。(主库从库都这样)
0 0
MySQL一主多从复制(基于GTID)
宿主机环境下,运行多个MySQL,实现数据的主从复制
0 0
剖析MySQL GTID复制
今儿的这篇博文,可以让大家快速了解GTID特性,并能灵活地运用到生产环境中,希望对大家有帮助。GTID原理介绍GTID又叫全局事务ID(Global Transaction ID),是一个已提交事务的编号,并且是一个全局唯一的编号。
715 0
MySQL运维实战 之 价值一个亿的GTID监控
一、背景 现在的MySQL可谓是拿着望远镜也找不到对手,其中有一个非常大的特性就是GTID GTID的原理这篇文章不再展开,有兴趣的同学可以关注之前的GTID原理,GTID实战,GTID运维实战文章。
2143 0
MySQL启用GTID的限制
开启 GTID 之后,会由部分的限制,内容如下: 更新非事务引擎表GTID 同步复制是基于事务的,所以 MyISAM 存储引擎不支持,这可能导致多个 GTID 分配给同一个事务。 使用GTID时,使用非事务性存储引擎(如MyISAM)对表的更新不能在与使用事务性存储引擎(如InnoDB)的表的更新相同的语句或事务中进行。
1305 0
+关注
技术小能手
云栖运营小编~
文章
问答
文章排行榜
最热
最新
相关电子书
更多
让 MySQL 原生分布式触手可及
立即下载
好的 MySQL 兼容可以做到什么程度
立即下载
云数据库RDS MySQL从入门到高阶
立即下载