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

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

为何 InnoDB 引擎会引入 redo 日志做为中间层来保证 MySQL 持久化，而不是直接持久化到磁盘？咱们先来看看《MySQL实战45讲》中提到的一个故事。

在《孔乙己》这篇文章，酒店掌柜有一个粉板，专门用来记录客人的赊帐记录。若是赊帐的人很少，那么他能够把顾客名和帐目写在板上。但若是赊帐的人多了，粉板总会有记不下的时候，这个时候掌柜必定还有一个专门记录赊帐的帐本。

若是有人要赊帐或者还帐的话，掌柜通常有两种作法：

• 一种作法是直接把帐本翻出来，把此次赊的帐加上去或者扣除掉；
• 另外一种作法是先在粉板上记下此次的帐，等打烊之后再把帐本翻出来核算。

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

这整个过程想一想都麻烦。相比之下，仍是先在粉板上记一下方便。你想一想，若是掌柜没有粉板的帮助，每次记帐都得翻帐本，效率是否是低得让人难以忍受？

一样，在 MySQL 里也有这个问题，磁盘就相对于帐本，若是每一次的更新操做都须要写进磁盘，而后磁盘也要找到对应的那条记录，而后再更新，整个过程 IO 成本、查找成本都很高。

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

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

经过上面的这个故事你能够理解为何须要引入 redo 日志，对 redo 日志有必定的了解，下面咱们就来正式介绍 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 的操做。从头开始写，写到末尾就又回到开头循环写，以下面这个图所示：

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 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、一、2 三个选项，在我装的 MySQL 下默认的是 1，简单介绍一下这三个选项的区别：

• 0：表示当提交事务时，并不将缓冲区的 redo 日志写入磁盘的日志文件，而是等待主线程每秒刷新。
• 1：在事务提交时将缓冲区的 redo 日志同步写入到磁盘，保证必定会写入成功。
• 2：在事务提交时将缓冲区的 redo 日志异步写入到磁盘，即不能彻底保证 commit 时确定会写入 redo 日志文件，只是有这个动做。

咱们使用默认值 1 就好，这样能够保证 MySQL 异常重启以后数据不丢失。

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

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

最后

目前互联网上不少大佬都有 MySQL 相关文章，若有雷同，请多多包涵了。原创不易，码字不易，还但愿你们多多支持。若文中有所错误之处，还望提出，谢谢。

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