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://xiahunao.cn/news/3017640.html

如若内容造成侵权/违法违规/事实不符，请联系瞎胡闹网进行投诉反馈，一经查实，立即删除！

相关文章

这些CTF，不仅学技术，还有巨额奖金！

这些CTF，不仅学技术，还有巨额奖金！

前言： 不会吧，不会吧，不会还有安全er不知道CTF是什么吧？ 在程序员的世界里，也有ACM这样的编程大赛，成为各路编程高手一较高下展示能力的平台。 那在网络安全的圈子里，各路黑客红客白帽子们又…
阅读更多...
Flutter弹窗链-顺序弹出对话框

Flutter弹窗链-顺序弹出对话框

效果 前言 弹窗的顺序执行在App中是一个比较常见的应用场景。比如进入App首页，一系列的弹窗就会弹出。如果不做处理就会导致弹窗堆积的全部弹出，严重影响用户体验。 如果多个弹窗中又有判断逻辑，根据点击后需要弹出另一个弹窗，这…
阅读更多...
Gradle 进阶学习 之 build.gradle 文件

Gradle 进阶学习 之 build.gradle 文件

build.gradle 是什么？ 想象一下，你有一个大型的乐高项目，你需要一个清单来列出所有的乐高积木和它们如何组合在一起。在软件开发中，build.gradle 就是这个清单，它告诉计算机如何构建（组合）你的软…
阅读更多...
《Linux运维总结：ARM架构CPU基于docker-compose一离线部署consul v1.18.1集群工具》

《Linux运维总结：ARM架构CPU基于docker-compose一离线部署consul v1.18.1集群工具》

总结：整理不易，如果对你有帮助，可否点赞关注一下？ 更多详细内容请参考：《Linux运维篇：Linux系统运维指南》 一、部署背景 由于业务系统的特殊性，我们需要面向不通的客户安装我们的业务系统&…
阅读更多...
【备战软考(嵌入式系统设计师)】09 - 嵌入式软件设计基础

【备战软考(嵌入式系统设计师)】09 - 嵌入式软件设计基础

嵌入式软件开发原理 嵌入式软件开发和我们传统的软件开发不一样。 就拿我们的QT开发，我们敲完代码之后直接编译运行exe看看效果，不行就改改再次编译运行，如果可以就打包exe文件相关的配置文件对吧，一套下来行云流水一气呵成。 …
阅读更多...
Kansformer?变形金刚来自过去的新敌人

Kansformer?变形金刚来自过去的新敌人

​1.前言 多层感知器(MLPs),也被称为全连接前馈神经网络,是当今深度学习模型的基础组成部分。 MLPs在机器学习中扮演着至关重要的角色,因为它们是用于近似非线性函数的默认模型,这得益于通用近似定理所保证的表达能力。然而,MLPs真的是我们能构建的最佳非线性回归器吗?尽管ML…
阅读更多...
免费在线录屏、无需注册、免费可用、无限制

免费在线录屏、无需注册、免费可用、无限制

免费在线工具 https://orcc.online/ 在线录屏 https://orcc.online/recorder pdf在线免费转word文档 https://orcc.online/pdf 时间戳转换 https://orcc.online/timestamp Base64 编码解码 https://orcc.online/base64 URL 编码解码 https://orcc.online/url Hash(MD5/SHA…
阅读更多...
5.7 线程

5.7 线程

进程：解耦稳定，内容之间是不相关的，通信不便利，理论上进程的软硬件的切换时间以及创建开销非常大。--------》资源共享线程实现 线程的问题：本质就是不解耦，一个出问题别的就很有可能出问题，同…
阅读更多...
关于获取邮件授权码

关于获取邮件授权码

以网易邮箱为例: 第一步:登录之后点击设置 第二步:点击POP3/SMTP/IMAP 第三步:开启SMTP服务 开启哪个都可以 第四步: 扫描二维码开启服务 第五步: 使用手机扫面二维码发送短信 第六步: 得到授权码 将授权码写入配置文件
阅读更多...
04-28 周日 FastAPI Post请求同时传递文件和普通参数

04-28 周日 FastAPI Post请求同时传递文件和普通参数

04-28 周日 FastAPI Post请求同时传递文件和普通参数 时间版本修改人描述04-28 周日V0.1宋全恒新建文档2024年5月6日14:20:05V1.0宋全恒完成文档的传递 简介 由于在重构FastBuild的时候，为了支持TLS是否启用，在接口中需要同时传递文件参数和其他参数&am…
阅读更多...
matlab 基于拉依达检验法（3σ准则） 实现多类别多参数的批量异常样本检验 V2.0

matlab 基于拉依达检验法（3σ准则） 实现多类别多参数的批量异常样本检验 V2.0

简介 拉依达检验法（3σ准则）是一种统计学方法，用于检测数据中的异常值。这种方法基于正态分布的特性来确定数据点是否可能是异常值。以下是关于拉依达检验法（3σ准则）的详细介绍： 基本原理： 拉…
阅读更多...
代码随想录第四十六天|单词拆分

代码随想录第四十六天|单词拆分

题目链接：. - 力扣（LeetCode）
阅读更多...
2.4V转3.8V/3.9V供电升压方案：为水表提供稳定电力

2.4V转3.8V/3.9V供电升压方案：为水表提供稳定电力

随着科技的不断发展，水表等智能设备在我们的生活中扮演着越来越重要的角色。为了让水表得以正常工作，稳定的电力供应是至关重要的。在这篇文章中，我们将探讨一种2.4V转3.8V/3.9V供电方案，以确保为水表提供稳定的电力。 为了实现2…
阅读更多...
每日两题 / 138. 随机链表的复制 148. 排序链表（LeetCode热题100）

每日两题 / 138. 随机链表的复制 148. 排序链表（LeetCode热题100）

138. 随机链表的复制 - 力扣（LeetCode） 用哈希表记录原链表中的节点是否被复制过 遍历原链表并通过哈希表维护新链表 /* // Definition for a Node. class Node { public:int val;Node* next;Node* random;Node(int _val) {val _val;next NULL;rand…
阅读更多...
STM32F407VET6 学习笔记1：GPIO引脚认识分类与开发板原理图

STM32F407VET6 学习笔记1：GPIO引脚认识分类与开发板原理图

今日学习STM32F407VET6 ，首先从基本原理图、引脚方面开始做个初步理解并整理： 这里使用的学习开发板是在嘉立创购买的 立创梁山派天空星，芯片是 STM32F407VET6 主要对这个芯片的引脚做一些归纳认识、对开发学习板原理图设计进行认识理解:最…
阅读更多...
23 JavaScript学习：验证API

23 JavaScript学习：验证API

JavaScript验证API 举例&#xff1a; <input id"id1" type"number" min"100" max"300" required> <button onclick"myFunction()">验证</button><p id"demo"></p><script>f…
阅读更多...
HarmonyOS实战开发-如何实现Web组件中网页长截图。

HarmonyOS实战开发-如何实现Web组件中网页长截图。

介绍 本案例实现了Web组件中网页长截图的方案。支持截图后展示大小浮窗预览、保存图片到相册、手势左滑关闭等功能。 效果图预览 实现思路 本解决方案通过循环滚动Web组件&#xff0c;每次滚动截取当前状态后拼接到离屏画布&#xff0c;最后一次性转为PixelMap图片并显示在全…
阅读更多...
Arduino PlatformIO避坑记

Arduino PlatformIO避坑记

实在受不了Arduino IDE上古时期的界面风格&#xff0c;最要命的是编译速度慢到极点&#xff0c;好在有PlatformIO。VS搭配PlatformIO&#xff0c;有微软加持&#xff0c;界面自然是妥妥的了&#xff0c;编译速度提升也肉眼可见。 至于PlatformIO的安装过程&#xff0c;网上教程…
阅读更多...
Day 24 数据库管理及数据类型

Day 24 数据库管理及数据类型

数据库管理及数据类型 一&#xff1a;数据类型 1.数值类型 整数类型 ​ 整数类型&#xff1a;TINYINT SMALLINT MEDIUMINT INT BIGINT ​ 作用&#xff1a;用于存储用户的年龄、游戏的Level、经验值等 浮点数类型 ​ 浮点数类型&#xff1a;FLOAT DOUBLE ​ 作用&#xf…
阅读更多...
超疏水TiO₂纳米纤维网膜的良好性能

超疏水TiO₂纳米纤维网膜的良好性能

超疏水TiO₂纳米纤维网膜是一种具有特殊性能的材料&#xff0c;它结合了TiO₂的光催化性能和超疏水表面的自清洁、防腐、防污等特性。这种材料在防水、自清洁、油水分离等领域具有广阔的应用前景。 制备超疏水TiO₂纳米纤维网膜的过程中&#xff0c;通过精确控制纺丝溶液的成分…
阅读更多...
最新文章

Copyright @ 2022~2023