mysql日志redo_MySQL 持久化保障机制-redo 日志

我们在 聊一聊 MySQL 中的事务及其实现原理 中提到了 redo 日志,redo 日志是用来…

我们在 聊一聊 MySQL 中的事务及其实现原理 中提到了 redo 日志,redo 日志是用来保证 MySQL 持久化功能的,需要注意的是 redo 日志是 InnoDB 引擎特有的功能。

为什么 InnoDB 引擎会引入 redo 日志作为中间层来保证 MySQL 持久化,而不是直接持久化到磁盘?我们先来看看《MySQL实战45讲》中提到的一个故事。

在《孔乙己》这篇文章,酒店掌柜有一个粉板,专门用来记录客人的赊账记录。如果赊账的人不多,那么他可以把顾客名和账目写在板上。但如果赊账的人多了,粉板总会有记不下的时候,这个时候掌柜一定还有一个专门记录赊账的账本。

如果有人要赊账或者还账的话,掌柜一般有两种做法:

一种做法是直接把账本翻出来,把这次赊的账加上去或者扣除掉;

另一种做法是先在粉板上记下这次的账,等打烊以后再把账本翻出来核算。

在生意红火柜台很忙时,掌柜一定会选择后者,因为前者操作实在是太麻烦了。首先,你得找到这个人的赊账总额那条记录。你想想,密密麻麻几十页,掌柜要找到那个名字,可能还得带上老花镜慢慢找,找到之后再拿出算盘计算,最后再将结果写回到账本上。

这整个过程想想都麻烦。相比之下,还是先在粉板上记一下方便。你想想,如果掌柜没有粉板的帮助,每次记账都得翻账本,效率是不是低得让人难以忍受?

同样,在 MySQL 里也有这个问题,磁盘就相对于账本,如果每一次的更新操作都需要写进磁盘,然后磁盘也要找到对应的那条记录,然后再更新,整个过程 IO 成本、查找成本都很高。

为了解决这个问题,MySQL 的设计者就用了类似酒店掌柜粉板的思路来提升更新效率,redo 日志跟酒店粉板一样,用来临时存储,承担一个中转的角色。

具体来说,当有一条记录需要更新的时候,InnoDB 引擎就会先把记录写到 redo log(粉板)里面,并更新内存,这个时候更新就算完成了。同时,InnoDB 引擎会在适当的时候,将这个操作记录更新到磁盘里面,而这个更新往往是在系统比较空闲的时候做,这就像打烊以后掌柜做的事。

通过上面的这个故事你可以理解为什么需要引入 redo 日志,对 redo 日志有一定的了解,下面我们就来正式介绍 redo 日志,先从 redo 日志的结构开始:

4971c03dff6091efa4b87156f5b08e67.png

上面是 redo 日志的通用结构,redo 日志记录的是每个页面(page)更改物理情况,所以 redo 日志整体来说是比较小的,存储的信息不多,简单的介绍一下这几个字段的意思:

type:该条redo日志的类型。

space ID:表空间ID。

page number:页号。

data:该条redo日志的具体内容。

redo 日志并非这么简单,它非常的复杂,但是我们不需要对它庖丁解牛,因为它确实对我们来说没啥用,我们只要记住 redo 日志会把事务在执行过程中对数据库所做的所有修改都记录下来,在之后系统崩溃重启后可以把事务所做的任何修改都恢复出来。

在事务提交时将所有修改过的内存中的页面刷新到磁盘中相比,只将该事务执行过程中产生的 redo 日志刷新到磁盘的好处如下:

redo日志占用的空间非常小:存储表空间ID、页号、偏移量以及需要更新的值所需的存储空间是很小的

redo日志是顺序写入磁盘的:在执行事务的过程中,每执行一条语句,就可能产生若干条redo日志,这些日志是按照产生的顺序写入磁盘的,也就是使用顺序IO。

redo 日志工作原理

redo 日志是循环写入的,因为 InnoDB 的 redo log 是固定大小的,比如可以配置为一组 4 个文件,每个文件的大小是 1GB,那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写,写到末尾就又回到开头循环写,如下面这个图所示:

bf5e8edf4650b8dd2f544fd7776b9d52.png

write pos 是当前记录的位置,一边写一边后移,写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置,也是往后推移并且循环的,擦除记录前要把记录更新到数据文件。

write pos 和 checkpoint 之间的是“粉板”上还空着的部分,可以用来记录新的操作。如果 write pos 追上 checkpoint,表示“粉板”满了,这时候不能再执行新的更新,得停下来先擦掉一些记录,把 checkpoint 推进一下。

这大概就是 redo 日志的工作原理,你就把它想象成一块黑板就好了。

redo日志缓冲区

redo 日志并不是直接写入磁盘的,而是先写入到缓存区,我们把这个缓冲区叫做 redo日志缓冲区。在服务器启动时就向操作系统申请了一大片称之为 redo log buffer 的连续内存空间,我们也可以简称为log buffer。这片内存空间被划分成若干个连续的 redo log block,如下图所示:

3f69999edebf3104468627d1548a034c.png

在 MySQL Server 5.7 下 redo日志缓冲区的大小默认为 1M,我们可以通过 innodb_log_buffer_size 参数来设置 redo 日志缓冲区的大小。

向 log buffer 中写入 redo 日志的过程是顺序的,也就是先往前边的 block中写,当该 block 的空闲空间用完之后再往下一个 block 中写。

先写入缓冲区再写磁盘,就会碰到一个问题,这个问题在 redis AOF 持久化方式时也遇到过,就是缓冲区和磁盘之间的数据如何同步?

在 MySQL 的配置文件中提供了 innodb_flush_log_at_trx_commit 参数,这个可以用来控制缓冲区和磁盘之间的数据如何同步,这里有 0、1、2 三个选项,在我装的 MySQL 下默认的是 1,简单介绍一下这三个选项的区别:

0:表示当提交事务时,并不将缓冲区的 redo 日志写入磁盘的日志文件,而是等待主线程每秒刷新。

1:在事务提交时将缓冲区的 redo 日志同步写入到磁盘,保证一定会写入成功。

2:在事务提交时将缓冲区的 redo 日志异步写入到磁盘,即不能完全保证 commit 时肯定会写入 redo 日志文件,只是有这个动作。

我们使用默认值 1 就好,这样可以保证 MySQL 异常重启之后数据不丢失。

总结一下 redo 日志是 InnoDB 引擎特有的,有了 redo 日志 之后,InnoDB 就可以保证即使数据库发生异常重启,之前提交的记录都不会丢失。

这篇文章从为什么要引入 redo 日志、redo 日志的结构和 redo 日志的写入方式三个方面简单聊了一下 MySQL 持久化保障机制 redo 日志,这东西可能工作没啥用,面试时候可能用的上,希望这篇文章对你的学习或者工作有所帮助,感谢您的阅读,如果您觉得文章有收获,欢迎点个赞和转发,谢谢。

最后

目前互联网上很多大佬都有 MySQL 相关文章,如有雷同,请多多包涵了。原创不易,码字不易,还希望大家多多支持。若文中有所错误之处,还望提出,谢谢。

欢迎扫码关注微信公众号:「平头哥的技术博文」,和平头哥一起学习,一起进步。

c75901ff858202f08301fa37f3ae6064.png

本文来自网络,不代表软粉网立场,转载请注明出处:https://www.rfff.net/p/5928.html

作者: HUI

发表评论

您的电子邮箱地址不会被公开。

返回顶部