MySQL 5.6 全局事务 ID(GTID)实现原理(三)

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 这是 MySQL 5.6 全局事务 ID(GTID) 系列的第三篇博客。   在之前的两篇博客中,第一篇​ 介绍了全局事务 ID 的定义与数据结构。第二篇​ 介绍了 MySQL 5.6 新增的全局事务状态(Gtid_state)。

这是 MySQL 5.6 全局事务 ID(GTID) 系列的第三篇博客。

 
在之前的两篇博客中, 第一篇​ 介绍了全局事务 ID 的定义与数据结构。 第二篇​ 介绍了 MySQL 5.6 新增的全局事务状态(Gtid_state)。
 
这里准备介绍的是全局事务 ID 如何参与 MySQL 的主备复制流程。
 
MySQL 5.6 引入全局事务 ID 的首要目的,是保证 Slave 在复制的时候不会重复执行相同的事务操作;其次,是用全局事务 IDs 代替由文件名和物理偏移量组成的复制位点,定位 Slave 需要复制的 binlog 内容。
 
因此,MySQL 必须在写 binlog 时记录每个事务的全局 GTID,保证 Master / Slave 可以根据这些 GTID 忽略或者执行相应的事务。在实现上,MySQL 没有修改旧的 binlog 事件,而是新增了两类事件:
 
+----------------------------+----------------------------------------+
| 名称                                    | 功能                                                      |
+----------------------------+----------------------------------------+
| Previous_gtids_log_event | 该事件之前的全局事务 ID 集合。          |
+----------------------------+----------------------------------------+
|                  Gtid_log_event | 标记之后的事务对应的全局事务 ID。    |
+----------------------------+----------------------------------------+
 
Gtid_log_event
 
在 MySQL 5.6 的 binlog 文件中,每个事务的开始不是 "BEGIN" ,而是 Gtid_log_event 事件:
 
(图片来源: MySQL_Innovation_Day_Replication_HA.pdf​)
 
它里面只包含一条 GTID,记录结构如下:
 
Gtid_log_event := (commit_flag, sid, gno)   // commit_flag 目前总是 true
 
里面 sid 就是产生该事务的 server_uuid,gno 是顺序编号的 transaction_id。
 
把 Gtid 记录在事务的开头是为了便于 MySQL 过滤 binlog:检查到某个 Gtid 不需要时,可以直接忽略后面的整段事务。
 
MySQL 5.6 保证同时写入 Gtid_log_event 和全局 logged_gtids 状态:
 
第一步,在向 binlog_cache_data 写入第一条 binlog 前,MySQL 会在缓存的 buffer 中写入一个空的 Gtid_log_event 占位。
 
第二步,当 binlog_cache_data 的内容刷到 binlog 文件时,MySQL 会把位于缓存 buffer 的 Gtid_log_event 内容替换成实际的 GTID,重新写入缓存。
 
最后,MySQL 调用 Gtid_state 的 update_on_flush() 把 GTID 写入 logged_gtids,再调用 sync_binlog_file()  保证内容更新到磁盘。 
 
在主备复制中,Slave 不像 Master 那样自动产生 GTID,而是直接拷贝 Gtid_log_event 中包含的 GTID。这个特性是这样实现的 —— MySQL 5.6 维护了一个线程(Session)级别的变量  gtid_next,类型为 Gtid_specification:
 
Gtid_specification := (enum_group_type, Gtid)
 
enum_group_type :=enum(AUTOMATIC_GROUP, GTID_GROUP, ANONYMOUS_GROUP, INVALID_GROUP, UNDEFINED_GROUP)
 
在 Master 执行事务时,gtid_next 的类型默认是 AUTOMATIC_GROUP,表示应该调用 generate_automatic_gno() 自动产生全局事务 ID。
 
而在 Slave 执行事务时,先用 Gtid_log_event 内的 Gtid 覆盖 gtid_next,使它的类型为 GTID_GROUP。这样的话,MySQL 会使用 gtid_next 内设置的 Gtid  值作为下一个全局事务 ID。
 
Previous_gtids_log_event
 
这个事件出现在 MySQL 5.6 每个 binlog 文件的开始处。
 
MySQL 创建一个新的 binlog 文件后,首先写入一个 Format_description_log_event 描述,接着写入一个 Previous_gtids_log_event,内容是在创建这个 binlog 文件之前执行的全局事务 GTIDs。 
 
事件的格式很简单,就是字符串编码的 Gdit_set:(编码格式参考本文  第一篇​)
 
Previous_gtids_log_event := buffer of Gtid_set
(例如:3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5)
 
这个事件只是作为记录。在主备复制时,Slave 会忽略 binlog 里的 Previous_gtids_log_event 事件。
 
Binlog 与持久化全局事务状态
 
在  上一篇​ 没有讲到 MySQL 5.6 如何持久化全局事务状态的 —— logged_gtids 和 lost_gtids 状态里存储了这台数据库  有史以来 执行的所有 GTIDs(包括删除 binlog 中的 GTIDs)—— 如果数据库停机或崩溃前不做持久化,之后肯定丢失信息。
 
MySQL 的解决方案很简单,在启动时扫描剩余的 binlog 文件,用文件存储的 Previous_gtids_log_event 和 Gtid_log_event 事件内容恢复全局 logged_gtids 和 lost_gtids 状态。
 
具体的代码如下:(源代码:mysql-5.6.9-rc\sql\binlog.cc,line 2558)
 
第一步,找到最后一个 binlog 文件,读出 Previous_gtids_log_event 记录;再遍历 binlog 文件中所有的 Gtid_log_event,  把找到的 GTID 记录合并起来,作为这台数据库历史上执行的所有 GTIDs 放入全局 logged_gtids 记录;
 
第二步,找到第一个 binlog 文件,用它的 Previous_gtids_log_event 信息代替全局 lost_gtids 的内容。因为这是第一个未删除的 binlog 文件,这里记录的就是之前已经删除的 binlog 文件所包含的全部 GTIDs。
 
由于 MySQL 在提交事务中是最后才写入真实 Gtid_log_event 信息的,从 binlog 恢复信息,可以保证读到的 GTIDs 与成功执行的事务一致。
 
CHANGE MASTER TO ... 
 
MySQL 5.6 主备复制的一个改变,是新增了 COM_BINLOG_DUMP_GTID 协议,支持在 Slave 切换到新 Master 时,用 MASTER_AUTO_POSITION = 1 (auto_position 方式)代替原来的 binlog 文件名和物理偏移量。
 
COM_BINLOG_DUMP_GTID 协议并不复杂,请求格式如下:

 

Request = { server_id, binlog_name, binlog_offset, gtids_executed }  
 
如果采用 auto_position 方式连接 Master,现在 Slave 发送的 binlog_name 和 binlog_offset 都是空白,Master 只使用 gtids_executed 定位 Slave 上需要执行的 binlog。
 
实现逻辑是这样的:Master 从第一个文件开始读取 binlog,逐个检查 Gdit_log_event 事件的全局事务 ID 是不是包含在 Slave 发送的 gtids_executed 集合中。如果发现这个 GTID 已经包含在 gtids_executed 集合内,就忽略后面的整段事务,不向 Slave 发送 binlog 内容。
 
其实这个过程还不是很优化,因为如果是正常情况,Master 需要遍历若干 G 的 binlog 才能找到 Slave 需要复制的 binlog 内容 —— 这应该是一个改进点。
 
全局事务 ID 与并发复制
 
MySQL 5.6 主备复制的另一个改变,是实现了多线程并行复制。这个功能必须有全局事务 ID 的支持,原因是:
 
1) 在并行复制方式下,有些操作是不按照记录在 binlog 中的顺序执行的。这样的话,如果按照文件名 + 物理偏移量的方式记录复制位点,则停止 / 恢复主备复制时,可能会有一些操作被重复执行。
 
2) 我们知道,即使是 Mixed / Row 模式下记录的 binlog,仍有些 DDL 操作是用 Statement 的方式编码的,这些 DDL 操作不能在 Slave 重复执行(因为非幂等)。一旦操作在 Slave 执行出错,结果就是复制中断。
 
因此,Slave 必须依赖 binlog 中的全局事务 ID,在停止 / 恢复主备复制时,精确的记录哪些事务在 Slave 执行过,哪些没有。
 
现在,MySQL 5.6 可以用 COM_BINLOG_DUMP_GTID 来保证这一点:在恢复主备复制时,Slave 向 Master 发送自己所有执行过的 GTIDs(logged_gtids),在上次中断主备复制时,已经执行过的 binlog 被 Master 直接滤掉,不向 Slave 传送。
 
总结
 
在主备复制上,MySQL 5.6 新增了三个特性:
 
1)使用 GTIDs 作为主备复制的位点,在写 binlog 时用 Gtid_log_event 标记事务。
 
2)支持 auto_position 方式进行主备切换。在新增的协议中,使用 GTIDs 作为复制位点向主库请求 binlog 信息。
 
3)多线程并发复制,使用 GTIDs 防止事务重复执行。
 
全局事务 ID(GTID)可以很好的支持这几个功能。而且,使用 GTIDs 避免了在传送 binlog 逻辑上依赖文件名和物理偏移量,能够更好的支持自动容灾切换。
 
但是个人感觉,全局事务 ID 这里还有些待解决的问题:
 
1)GTID 是局部有序的,不能记录事务的全局顺序。因此在双写 / 快速主备切换场景下,不能根据 GTID 顺序来解决更新冲突的问题。
 
2)容灾切换时,MASTER_AUTO_POSITION 只能解决记录位点的问题。为了保证一致性,停写和等待主备 Caught up 仍然是必须的,通常这是服务无法快速恢复的主要原因。
 
补充:参考资料
 
这篇博客用到的参考资料:
 
MySQL 5.6 Manual:Replication with Global Transaction Identifiers( link​)

​​WL#4677: Unique Server Ids for Replication Topology (UUIDs)​​(link​)

WL#3584: Global Transaction Identifiers (GTIDs)( link​)

​​

顺便提下, MySQL Worklog​ 是个好地方,你可以从这里了解 MySQL 的原始需求,开发人员的想法,还有值得关注的问题。
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
MySQL实现文档全文搜索,分词匹配多段落重排展示,知识库搜索原理分享
本文介绍了在文档管理系统中实现高效全文搜索的方案。为解决原有ES搜索引擎私有化部署复杂、运维成本高的问题,我们转而使用MySQL实现搜索功能。通过对用户输入预处理、数据库模糊匹配、结果分段与关键字标红等步骤,实现了精准且高效的搜索效果。目前方案适用于中小企业,未来将根据需求优化并可能重新引入专业搜索引擎以提升性能。
MySQL原理简介—6.简单的生产优化案例
本文介绍了数据库和存储系统的几个主题: 1. **MySQL日志的顺序写和数据文件的随机读指标**:解释了磁盘随机读和顺序写的原理及对数据库性能的影响。 2. **Linux存储系统软件层原理及IO调度优化原理**:解析了Linux存储系统的分层架构,包括VFS、Page Cache、IO调度等,并推荐使用deadline算法优化IO调度。 3. **数据库服务器使用的RAID存储架构**:介绍了RAID技术的基本概念及其如何通过多磁盘阵列提高存储容量和数据冗余性。 4. **数据库Too many connections故障定位**:分析了MySQL连接数限制问题的原因及解决方法。
103 23
MySQL底层概述—9.ACID与事务
本文介绍了数据库事务的ACID特性(原子性、一致性、隔离性、持久性),以及事务控制的演进过程,包括排队、排它锁、读写锁和MVCC(多版本并发控制)。文章详细解释了每个特性的含义及其在MySQL中的实现方式,并探讨了事务隔离级别的类型及其实现机制。重点内容包括:ACID特性(原子性、持久性、隔离性和一致性的定义及其实现方式)、事务控制演进(从简单的全局排队到复杂的MVCC,逐步提升并发性能)、MVCC机制(通过undo log多版本链和Read View实现高效并发控制)、事务隔离级别(析了四种隔离级别(读未提交、读已提交、可重复读、可串行化)的特点及适用场景)、隔离级别与锁的关系。
MySQL原理简介—3.生产环境的部署压测
本文介绍了Java系统和数据库在高并发场景下的压测要点: 1. 普通系统在4核8G机器上每秒能处理几百个请求 2. 高并发下数据库建议使用8核16G或更高配置的机器 3. 数据库部署后需进行基准压测,以评估其最大承载能力 4. QPS和TPS的区别及重要性 5. 压测时需关注IOPS、吞吐量、延迟 6. 除了QPS和TPS,还需监控CPU、内存、磁盘IO、网络带宽 7. 影响每秒可处理并发请求数的因素包括线程数、CPU、内存、磁盘IO和网络带宽 8. Sysbench是数据库压测工具,可构造测试数据并模拟高并发场景 9. 在增加线程数量的同时,必须观察机器的性能,确保各硬件负载在合理范围
158 72
解决MySQL自增id用尽的问题
本文介绍了解决文章点击记录表(`article_click_record`)数据量激增问题的方案。由于用户量大,每天新增约400万条记录,导致表id接近溢出(2,100,000,000),且占用空间超320G。解决方案包括:1) 新建`article_click_record_new`表,将id类型改为BIGINT以避免溢出;2) 过渡阶段同时写入新旧表,待旧表id溢出后切换至新表;3) 定时清理过期数据或转移旧表内容。实现方式涉及修改相关接口和服务逻辑,确保业务平稳过渡。
RDS用多了,你还知道MySQL主从复制底层原理和实现方案吗?
随着数据量增长和业务扩展,单个数据库难以满足需求,需调整为集群模式以实现负载均衡和读写分离。MySQL主从复制是常见的高可用架构,通过binlog日志同步数据,确保主从数据一致性。本文详细介绍MySQL主从复制原理及配置步骤,包括一主二从集群的搭建过程,帮助读者实现稳定可靠的数据库高可用架构。
129 9
RDS用多了,你还知道MySQL主从复制底层原理和实现方案吗?
MySQL原理简介—9.MySQL索引原理
本文详细介绍了MySQL索引的设计与使用原则,涵盖磁盘数据页的存储结构、页分裂机制、主键索引设计及查询过程、聚簇索引和二级索引的原理、B+树索引的维护、联合索引的使用规则、SQL排序和分组时如何利用索引、回表查询对性能的影响以及索引覆盖的概念。此外还讨论了索引设计的案例,包括如何处理where筛选和order by排序之间的冲突、低基数字段的处理方式、范围查询字段的位置安排,以及通过辅助索引来优化特定查询场景。总结了设计索引的原则,如尽量包含where、order by、group by中的字段,选择离散度高的字段作为索引,限制索引数量,并针对频繁查询的低基数字段进行特殊处理等。
111 18
MySQL原理简介—9.MySQL索引原理
MySQL底层概述—6.索引原理
本文详细回顾了:索引原理、二叉查找树、平衡二叉树(AVL树)、红黑树、B-Tree、B+Tree、Hash索引、聚簇索引与非聚簇索引。
115 11
MySQL底层概述—6.索引原理
MySQL原理简介—12.MySQL主从同步
本文介绍了四种为MySQL搭建主从复制架构的方法:异步复制、半同步复制、GTID复制和并行复制。异步复制通过配置主库和从库实现简单的主从架构,但存在数据丢失风险;半同步复制确保日志复制到从库后再提交事务,提高了数据安全性;GTID复制简化了配置过程,增强了复制的可靠性和管理性;并行复制通过多线程技术降低主从同步延迟,保证数据一致性。此外,还讨论了如何使用工具监控主从延迟及应对策略,如强制读主库以确保即时读取最新数据。
MySQL原理简介—12.MySQL主从同步
MySQL原理简介—7.redo日志的底层原理
本文介绍了MySQL中redo日志和undo日志的主要内容: 1. redo日志的意义:确保事务提交后数据不丢失,通过记录修改操作并在系统宕机后重做日志恢复数据。 2. redo日志文件构成:记录表空间号、数据页号、偏移量及修改内容。 3. redo日志写入机制:redo日志先写入Redo Log Buffer,再批量刷入磁盘文件,减少随机写以提高性能。 4. Redo Log Buffer解析:描述Redo Log Buffer的内存结构及刷盘时机,如事务提交、Buffer过半或后台线程定时刷新。 5. undo日志原理:用于事务回滚,记录插入、删除和更新前的数据状态,确保事务可完整回滚。
156 22

推荐镜像

更多
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等