MySQL 持久化保障机制-redo 日志

栏目: IT技术 · 发布时间: 4年前

内容简介:技术文章第一时间送达!

点击 上方“ 平头哥的技术博文 ”,选择“ 关注公众号

技术文章第一时间送达!

MySQL 持久化保障机制-redo 日志

我们在 你可能知道事务的四大特性,但是你不一定知道事务的实现原理 中提到了 redo 日志,redo 日志是用来保证 MySQL 持久化功能的,需要注意的是 redo 日志是 InnoDB 引擎特有的功能。

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

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

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

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

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

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

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

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

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

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

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

MySQL 持久化保障机制-redo 日志
redo 日志通用结构

上面是 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 的操作。从头开始写,写到末尾就又回到开头循环写,如下面这个图所示:

MySQL 持久化保障机制-redo 日志
redo 日志

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

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

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

redo日志缓冲区

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

MySQL 持久化保障机制-redo 日志
redo日志缓冲区

在 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 持久化保障机制-redo 日志》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Adobe Flex 大师之路

Adobe Flex 大师之路

2009-5 / 69.80元

《Adobe Flex大师之路》以Flex 3.0为基础,涵盖了Flex技术的核心内容。《Adobe Flex 大师之路》能够帮助您你学习并掌握使用Flex所需的牢靠和全面的知识基础,告诉您你如何把这些知识将之转化为代码,并在实际项目中变通应用。通过学习《Adobe Flex 大师之路》,您你可以利用Flex来构建企业级应用的表现层、改善应用的用户体验、集成企业端的复杂服务。这本书是为所有希望学习......一起来看看 《Adobe Flex 大师之路》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器