MySQL日志机制【undo log、redo log、binlog 】

前言

SQL执行流程图文分析:从连接到执行的全貌_一条 sql 执行的全流程?-CSDN博客文章浏览阅读1.1k次,点赞20次,收藏12次。本文探讨 MySQL 执行一条 SQL 查询语句的详细流程,从连接器开始,逐步介绍了查询缓存、解析 SQL、执行计划优化以及执行器等各个功能模块的作用。同时,还解释了 MySQL 的内部架构,包括 Server 层和存储引擎层,并讨论了短连接与长连接、索引下推等相关概念。通过本文,读者能够全面了解 MySQL 在执行 SQL 查询时的内部工作原理,以及如何优化查询性能。_一条 sql 执行的全流程?https://blog.csdn.net/weixin_73077810/article/details/137524227以上文章是针对查询操作的流程剖析,这一套流程,更新语句也是同样会走一遍:不过,更新语句的流程会涉及到 undo log、redo log 、binlog 这三种日志:

  • undo log:Innodb 存储引擎层生成的日志,实现了事务中的原子性,主要用于事务回滚MVCC

  • redo log:Innodb 存储引擎层生成的日志,实现了事务中的持久性,主要用于掉电等故障恢复

  • binlog :是 Server 层生成的日志,主要用于数据备份和主从复制

下面就让我们好好深入的来学习一下这三类日志的细节,促进对于事务型SQL的执行过程的理解、

undo log

        undo log 是一种用于撤销回退的日志。在事务没提交之前,MySQL 会先记录更新前的数据到 undo log 日志文件里面,当事务回滚时,可以利用 undo log 来进行回滚。另外,undo log 还有一个作用,通过 ReadView + undo log 实现 MVCC(多版本并发控制)

redo log

        为了防止断电导致数据丢失的问题,当有一条记录需要更新的时候,InnoDB 引擎就会先更新内存(同时标记为脏页),然后将本次对这个页的修改以 redo log 的形式记录下来,这个时候更新就算完成了MySQL 的写操作并不是立刻写到磁盘上,而是先写日志,然后在合适的时间再写到磁盘上。在事务提交时,只要先将 redo log 持久化到磁盘即可,可以不需要等到将缓存在 Buffer Pool 里的脏页数据持久化到磁盘。当系统崩溃时,虽然脏页数据没有持久化,但是 redo log 已经持久化,接着 MySQL 重启后,可以根据 redo log 的内容,将所有数据恢复到最新的状态。

redo log 要写到磁盘,数据也要写磁盘,为什么要多此一举?

        写入 redo log 的方式使用了追加操作, 所以磁盘操作是顺序写,而写入数据需要先找到写入位置,然后才写到磁盘,所以磁盘操作是随机写。磁盘的「顺序写 」比「随机写」 高效的多,因此 redo log 写入磁盘的开销更小。

产生的 redo log 是直接写入磁盘的吗?

不是的。实际上, 执行一个事务的过程中,产生的 redo log 也不是直接写入磁盘的,因为这样会产生大量的 I/O 操作,而且磁盘的运行速度远慢于内存。

redo log 什么时候刷盘?

主要有下面几个时机:

  • MySQL 正常关闭时;

  • 当 redo log buffer 中记录的写入量大于 redo log buffer 内存空间的一半时,会触发落盘;

  • InnoDB 的后台线程每隔 1 秒,将 redo log buffer 持久化到磁盘。

redo log 文件写满了怎么办?

        默认情况下, InnoDB 存储引擎有 1 个重做日志文件组,「重做日志文件组」由有 2 个 redo log 文件组成,每个 redo log File 的大小是固定且一致的,重做日志文件组是以循环写的方式工作的,从头开始写,写到末尾就又回到开头,相当于一个环形。

所以 InnoDB 存储引擎会先写 ib_logfile0 文件,当 ib_logfile0 文件被写满的时候,会切换至 ib_logfile1 文件,当 ib_logfile1 文件也被写满时,会切换回 ib_logfile0 文件。

redo log 是循环写的方式,相当于一个环形,InnoDB 用 write pos 表示 redo log 当前记录写到的位置,用 checkpoint 表示当前要擦除的位置,如下图:

        如果 write pos 追上了 checkpoint,就意味着 redo log 文件满了,这时 MySQL 不能再执行新的更新操作,也就是说 MySQL 会被阻塞,此时会停下来将 Buffer Pool 中的脏页刷新到磁盘中,然后标记 redo log 哪些记录可以被擦除,接着对旧的 redo log 记录进行擦除,等擦除完旧记录腾出了空间,checkpoint 就会往后移动(图中顺时针),然后 MySQL 恢复正常运行,继续执行新的更新操作。

binlog

        MySQL 在完成一条更新操作后,Server 层还会生成一条 binlog写到 binlog cache(Server 层的 cache),等之后事务提交的时候,再把 binlog cache 写到 binlog 文件中。在此期间,事务中的binlog如果超过了binlog cache的大小,就要暂存到磁盘。虽然每个线程有自己 binlog cache,但是最终都写到同一个 binlog 文件

binlog 文件是记录了所有数据库表结构变更和表数据修改的日志,不会记录查询类的操作,比如 SELECT 和 SHOW 操作。

如果不小心整个数据库的数据被删除了,能使用 redo log 文件恢复数据吗?

        不可以使用 redo log 文件恢复,只能使用 binlog 文件恢复。因为 redo log 文件是循环写,是会边写边擦除日志的,只记录未被刷入磁盘的数据的物理日志,已经刷入磁盘的数据都会从 redo log 文件里擦除。

        binlog 文件保存的是全量的日志,也就是保存了所有数据变更的情况,理论上只要记录在 binlog 上的数据,都可以恢复,所以如果不小心整个数据库的数据被删除了,得用 binlog 文件恢复数据。

两阶段提交

        事务提交后,redo log 和 binlog 都要持久化到磁盘,但是这两个是独立的逻辑,可能出现半成功的状态,这样就造成两份日志之间的逻辑不一致。如果出现半成功状态,就会造成主从环境的数据不一致性。这是因为 redo log 影响主库的数据,binlog 影响从库的数据,所以 redo log 和 binlog 必须保持一致才能保证主从数据一致。

        MySQL 为了避免出现两份日志之间的逻辑不一致的问题,使用了「两阶段提交」来解决,两阶段提交其实是分布式事务一致性协议,它可以保证多个逻辑操作要不全部成功,要不全部失败,不会出现半成功的状态。

        两阶段提交把单个事务的提交拆分成了 2 个阶段,分别是「准备(Prepare)阶段」和「提交(Commit)阶段」,每个阶段都由协调者和参与者共同完成。注意,不要把提交阶段和 commit 语句混淆了,commit 语句执行的时候,会包含提交阶段。

举个拳击比赛的例子,两位拳击手(参与者)开始比赛之前,裁判(协调者)会在中间确认两位拳击手的状态,类似于问你准备好了吗?

  • 准备阶段:裁判(协调者)会依次询问两位拳击手(参与者)是否准备好了,然后拳击手听到后做出应答,如果觉得自己准备好了,就会跟裁判说准备好了;如果没有自己还没有准备好(比如拳套还没有带好),就会跟裁判说还没准备好。

  • 提交阶段:如果两位拳击手(参与者)都回答准备好了,裁判(协调者)宣布比赛正式开始,两位拳击手就可以直接开打;如果任何一位拳击手(参与者)回答没有准备好,裁判(协调者)会宣布比赛暂停,对应事务中的回滚操作。

两阶段提交的过程是怎样的?

为了保证这两个日志的一致性,MySQL 使用了内部 XA 事务,内部 XA 事务由 binlog 作为协调者,存储引擎是参与者。

当客户端执行 commit 语句或者在自动提交的情况下,MySQL 内部开启一个 XA 事务,分两阶段来完成 XA 事务的提交,如下图:

  • prepare 阶段:将 XID(内部 XA 事务的 ID) 写入到 redo log,同时将 redo log 对应的事务状态设置为 prepare,然后将 redo log 持久化到磁盘(innodb_flush_log_at_trx_commit = 1 的作用);

  • commit 阶段:把 XID 写入到 binlog,然后将 binlog 持久化到磁盘(sync_binlog = 1 的作用),接着调用引擎的提交事务接口,将 redo log 状态设置为 commit,此时该状态并不需要持久化到磁盘,只需要 write 到文件系统的 page cache 中就够了,因为只要 binlog 写磁盘成功,就算 redo log 的状态还是 prepare 也没有关系,一样会被认为事务已经执行成功;

在两阶段提交的不同时刻,MySQL 异常重启会出现什么现象?

不管是时刻 A(redo log 已经写入磁盘, binlog 还没写入磁盘),还是时刻 B (redo log 和 binlog 都已经写入磁盘,还没写入 commit 标识)崩溃,此时的 redo log 都处于 prepare 状态

在 MySQL 重启后会按顺序扫描 redo log 文件,碰到处于 prepare 状态的 redo log,就拿着 redo log 中的 XID 去 binlog 查看是否存在此 XID:

  • 如果 binlog 中没有当前内部 XA 事务的 XID,说明 redolog 完成刷盘,但是 binlog 还没有刷盘,则回滚事务。对应时刻 A 崩溃恢复的情况。

  • 如果 binlog 中有当前内部 XA 事务的 XID,说明 redolog 和 binlog 都已经完成了刷盘,则提交事务。对应时刻 B 崩溃恢复的情况。

        可以看到,对于处于 prepare 阶段的 redo log,即可以提交事务,也可以回滚事务,这取决于是否能在 binlog 中查找到与 redo log 相同的 XID,如果有就提交事务,如果没有就回滚事务。这样就可以保证 redo log 和 binlog 这两份日志的一致性了。

所以说,两阶段提交是以 binlog 写成功为事务提交成功的标识,因为 binlog 写成功了,就意味着能在 binlog 中查找到与 redo log 相同的 XID。

事务没提交的时候,redo log 会被持久化到磁盘吗?

会的。事务执行中间过程的 redo log 也是直接写在 redo log buffer 中的,这些缓存在 redo log buffer 里的 redo log 也会被「后台线程」每隔一秒一起持久化到磁盘。

修改操作流程

三个日志讲完了,至此我们可以先小结下,update 语句的执行过程。

当优化器分析出成本最小的执行计划后,执行器就按照执行计划开始进行更新操作。

具体更新一条记录 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 的流程如下:

  1. 执行器负责具体执行,会调用存储引擎的接口,通过主键索引树搜索获取 id = 1 这一行记录:

    • 如果 id=1 这一行所在的数据页本来就在 buffer pool 中,就直接返回给执行器更新;

    • 如果记录不在 buffer pool,将数据页从磁盘读入到 buffer pool,返回记录给执行器。

  2. 执行器得到聚簇索引记录后,会看一下更新前的记录和更新后的记录是否一样:

    • 如果一样的话就不进行后续更新流程;

    • 如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层,让 InnoDB 真正的执行更新记录的操作;

  3. 开启事务, InnoDB 层更新记录前,首先要记录相应的 undo log,因为这是更新操作,需要把被更新的列的旧值记下来,也就是要生成一条 undo log,undo log 会写入 Buffer Pool 中的 Undo 页面,不过在内存修改该 Undo 页面后,需要记录对应的 redo log。

  4. InnoDB 层开始更新记录,会先更新内存(同时标记为脏页),然后将记录写到 redo log 里面,这个时候更新就算完成了。为了减少磁盘I/O,不会立即将脏页写入磁盘,后续由后台线程选择一个合适的时机将脏页写入到磁盘。这就是 WAL 技术,MySQL 的写操作并不是立刻写到磁盘上,而是先写 redo 日志,然后在合适的时间再将修改的行数据写到磁盘上。

  5. 至此,一条记录更新完了。

  6. 在一条更新语句执行完成后,然后开始记录该语句对应的 binlog,此时记录的 binlog 会被保存到 binlog cache,并没有刷新到硬盘上的 binlog 文件,在事务提交时才会统一将该事务运行过程中的所有 binlog 刷新到硬盘。

  7. 事务提交,剩下的就是「两阶段提交」的事情了

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mfbz.cn/a/598604.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

xmind的13个快捷方式

1.新建导图 CtrlshiftN 2.编辑文字 空格键 3.插入图片 Ctrli 4. 插入主题 Enter键 5. 插入主题之前 ShiftEnter键 6. 插入子主题 Tab键 7. 放大导图 “Ctrl”“” 8. 缩小导图 “Ctrl”“-” 9. 复制 CtrlInsert 10. 粘贴 Shift Insert 11. 剪切 ShiftDelete 12. 截图 F7 13. 保…

【Pytorch】5.DataLoder的使用

什么是DataLoader 个人理解是,如果Dataset的所有数据相当于一副扑克牌,DataLoader就相当于从扑克牌中抽取几张,我们可以规定一次抽取的张数,或者以什么规则进行抽取 DataLoader的使用 查阅官网的文档,主要有这几个参数…

Unity Shader中获取像素点深度信息

1.顶点着色器中对深度进行计算 v2f vert(appdata v) {v2f o;o.pos UnityObjectToClipPos(v.vertex);o.uv TRANSFORM_TEX(v.uv, _MainTex);o.depth (o.pos.z / o.pos.w 1.0) * 0.5; // Normalize depth to [0, 1]return o; }但是达不到预期,最后返回的值一直大于…

SpringMVC响应数据

三、SpringMVC响应数据 3.1 handler方法分析 理解handler方法的作用和组成: /*** TODO: 一个controller的方法是控制层的一个处理器,我们称为handler* TODO: handler需要使用RequestMapping/GetMapping系列,声明路径,在HandlerMapping中注册,供DS查找!* TODO: ha…

数据挖掘实战-基于深度学习RNN+CNN的能源价格预测模型

🤵‍♂️ 个人主页:艾派森的个人主页 ✍🏻作者简介:Python学习者 🐋 希望大家多多支持,我们一起进步!😄 如果文章对你有帮助的话, 欢迎评论 💬点赞&#x1f4…

java JMH 学习

JMH 是什么? JMH(Java Microbenchmark Harness)是一款专用于代码微基准测试的工具集,其主要聚焦于方法层面的基准测试,精度可达纳秒级别。此工具由 Oracle 内部负责实现 JIT 的杰出人士编写,他们对 JIT 及…

翻译《The Old New Thing》 - What is the deal with the ES_OEMCONVERT flag?

What is the deal with the ES_OEMCONVERT flag? - The Old New Thinghttps://devblogs.microsoft.com/oldnewthing/20050719-12/?p34893 Raymond Chen 在 2005年07月19日 ES_OEMCONVERT 标志是怎么回事? 简要 文章讨论了 ES_OEMCONVERT 编辑控件风格的起源和用途…

java将图片转为pdf

效果图 直接上代码 1.引入jar <dependency><groupId>org.apache.pdfbox</groupId><artifactId>pdfbox</artifactId><version>2.0.24</version></dependency> 2.测试类 package pers.wwz.study.img2pdf20240507;import org.a…

MetaCRM upload 任意文件上传漏洞

文章目录 漏洞描述漏洞原理漏洞复现修复建议 漏洞描述 北京美特软件技术有限公司&#xff08;以下简称“美特软件”&#xff09;是一家专业的客户关系管理软件提供商。 美特软件MetaCrm存在文件上传漏洞&#xff0c;攻击者可利用该漏洞上传任意恶意文件。 漏洞原理 在系统u…

什么牌子的骨传导耳机质量好?五大宝藏热门机型测评对比!

我作为一名音乐发烧友&#xff0c;对各类耳机产品都有深入的了解&#xff0c;最近也经常被人问及骨传导耳机哪个牌子好。通过交流&#xff0c;我发现很多人在选择骨传导耳机的时候&#xff0c;都有出现踩坑的情况&#xff0c;这也难怪&#xff0c;随着骨传导耳机热度逐渐增加&a…

护眼灯排名前十的品牌有哪些?护眼灯品牌排行前十名推荐

近视在儿童中愈发普遍&#xff0c;许多家长开始认识到&#xff0c;除了学业成绩之外&#xff0c;孩子的视力健康同样重要。毕竟&#xff0c;学业的落后可以逐渐弥补&#xff0c;而一旦孩子近视&#xff0c;眼镜便可能成为长期伴随。因此&#xff0c;专业的护眼台灯对于每个家庭…

220V转18V500mA非隔离恒压WT5113

220V转18V500mA非隔离恒压WT5113 亲爱的朋友们&#xff0c;你们是否在为如何提高电源方案而烦恼呢&#xff1f;今天我给大家带来了一款芯片&#xff0c;WT5113宽输出范围非隔离交直流转换芯片&#xff0c;它可是电源方案中的得力助手哦&#xff01; 这款芯片拥有220V降12V、2…

docker-compose 运行jenkins 并一键发布springboot项目

文档时间&#xff1a; 2024-05-07 jenkins一键发布原理个人理解&#xff1a; 本质就是通过jenkins 配置git地址&#xff0c;然后通过地址拉取代码到服务器上&#xff0c; 然后jenkins 再通过maven把拉取下来的进行打包。 再通过jenkins 配置的shell命令&#xff0c;在服务…

ubuntu20.04搭建Fabric教程

本章节环境配置 ubuntu: 20.04 go&#xff1a;1.16.3 docker: 20.10.6 docker-compose: 1.27.2 fabric&#xff1a;2.2.0 fabric-ca: 1.4.9 一 搭建通道 新建工作目录 mkdir fabric && cd fabric配置go代理 go env -w GO111MODULEon ​ #更新下载包的镜像 go env …

Python中GDAL批量将多个遥感影像各波段数值缩小10000倍的方法

本文介绍基于Python中的gdal模块&#xff0c;批量读取大量多波段遥感影像文件&#xff0c;分别对各波段数据加以数值处理&#xff0c;并将所得处理后数据保存为新的遥感影像文件的方法。 首先&#xff0c;看一下本文的具体需求。我们现有一个文件夹&#xff0c;其中含有大量.ti…

数据结构:环形链表的实战指南

✨✨小新课堂开课了&#xff0c;欢迎欢迎~✨✨ &#x1f388;&#x1f388;养成好习惯&#xff0c;先赞后看哦~&#x1f388;&#x1f388; 所属专栏&#xff1a;http://t.csdnimg.cn/oHJAK&#xff08;数据结构与算法&#xff09; 小新的主页&#xff1a;编程版小新-CSDN博客 …

嵌入式C语言教程:实现声音监测系统

声音监测在许多应用中都十分重要&#xff0c;如噪声控制、安全系统、和智能家居控制。 本教程将介绍如何在STM32微控制器上使用模数转换器&#xff08;ADC&#xff09;和声音传感器实现实时声音监测系统。 一、开发环境准备 硬件要求 微控制器&#xff1a;STM32F746NG&…

Unity技术学习:渲染大量物体的解决方案,外加RenderMesh、RenderMeshInstanced、RenderMeshIndirect的简单使用

叠甲&#xff1a;本人比较菜&#xff0c;如果哪里不对或者有认知不到的地方&#xff0c;欢迎锐评&#xff08;不玻璃心&#xff09;&#xff01; 导师留了个任务&#xff0c;渲染大量的、移动的物体。 寻找解决方案&#xff1a; 当时找了几个解决方案&#xff1a; 静态批处…

使用STM32的FLASH保存数据

使用STM32的FLASH保存数据 为了防止“掉电丢失数据”&#xff0c;我们最先想到的是EEPROM&#xff0c;但是若考虑到降低成本和PCB布线的空间&#xff0c;使用CPU内部的FLASH空间来保存数据&#xff0c;是最好的选择。尤其是在STM32芯片上&#xff0c;应用案例还是比较多的。 …

GitHub搭建免费博客

一、GitHub仓库准备 ​ 搭建博客需要准备两个仓库。一个存放博客图床的仓库&#xff0c;另一个存放博客网站的仓库。 1.1、图床创建 新建仓库 第一步&#xff1a; ​ 第二步&#xff1a; 生成Token令牌 点击右上角头像->Settings->下拉&#xff0c;直到左侧到底&#…
最新文章