MySQL进阶之RedoLog是个啥东西

redolog 有啥用

redo log 本质是保证事务提交之后，修改的数据绝对不会丢失的，那它是怎么做的呢？没有它会出现什么问题呢？

当你更新一条数据（增删改）时，会更新缓存页的数据，会更新free链表、flush链表、lru链表，然后有专门的后台IO线程，不定时的根据flush链表、lru链表，会把你更新过的缓存页刷新回磁盘文件的数据页里去。

但是有个问题就是假如一个事务里有增删改SQL更新了缓存页，然后事务提交了，结果还没来得及让IO线程把缓存页刷新到磁盘文件里，此时MySQL宕机了，然后内存数据丢失，事务更新的数据就丢失了。

那怎么办呢？
一个很简单的做法就是在事务提交完成之前把该事务所修改的所有页面都刷新到磁盘，但是这个简单粗暴的做法有些问题：

1. 缓存页默认16kb，数据比较大，刷入磁盘比较耗时，而且你可能就修改了缓存页里的几个字节的数据，就要刷新一个完整的数据页太浪费了。

2. 缓存页刷入磁盘是随机写磁盘，性能是很差的，因为缓存页对应的位置可能在磁盘文件的一个随机位置，尤其是一个事务可能包含很多语句，即使是一条语句也可能修改许多页面，如果该事务修改的这些页面并不相邻，那就意味着缓存页刷入磁盘需要进行很多的随机IO。

所以才引入一个redo log机制，redo log 由两部分组成，一个是内存中的重做日志缓冲（redo log buffer），它是容易丢失的，另外一个是重做日志文件（redo log file），它是持久的，

由于 InnoDB 存储引擎中 Force Log at Commit 机制，也就是提交事务时，必须先将该事务的所有重做日志写入重做日志文件进行持久化，才可以 Commit。

那针对上面“事务提交完成之前把该事务所修改的所有页面都刷新到磁盘”的办法， redo log 有啥优势呢？

1. 首先 redo log 占用空间小，redo log 是一种物理日志，记录的是页的物理修改操作，大致的格式如下：对表空间XX中的数据页XX中的偏移量为XXXX的地方更新了数据XXX。

2. redo log写日志，是顺序写入磁盘文件，每次都是追加到磁盘文件末尾去，速度也是很快的。

redo log 格式

redo log 到底长啥样呢？
redo log里本质上记录的就是 “在对某个表空间的某个数据页的某个偏移量的地方修改了几个字节的值，具体修改的值是什么”，所以他需要记录的就是“表空间号+数据页号+偏移量+修改几个字节的值+具体的值”。

所以根据修改了数据页里的几个字节的值，redo log就划分为了不同的类型：
MLOG_1BYTE 类型的日志指的就是修改了1个字节的值；
MLOG_2BYTE 类型的日志指的就是修改了2个字节的值；
以此类推，还有修改了4个字节的值的日志类型，修改了8个字节的值的日志类型。

当然，如果你要是一下子修改了一大串的值，类型就是 MLOG_WRITE_STRING，就是代表你一下子在那个数据页的某个偏移量的位置插入或者修改了一大串的值。

虽然有着不同重做日志格式，但是它们都有着通用的格式

• redo_log_type：该条redo日志的类型。
  在MySQL 5.7.21这个版本中，redo日志设计了53种不同的类型。
• space：表空间ID。
• page_no：页号。
• redo_log_body：该条redo日志的具体内容

而 redo_log_body 部分，根据重做日志的类型不同，会有不同的存储内容，例如，对页上的插入和删除操作：

大致就是一条redo log中依次排列上述的一些东西，redo log表达的语义就明确了，他的类型是什么，类型就表明了这次增删改操作修改了多少字节的数据；然后在哪个表空间里操作的，接着就是在这个表空间的哪个数据页里执行的，在数据页的哪个偏移量开始执行的，具体更新的数据是哪些呢。

有了上述信息，就可以还原出来一次数据增删改操作做的变动了。 只不过如果是MLOG_WRITE_STRING类型的日志，因为不知道具体修改了多少字节的数据，所以其实会多一个修改数 据长度，就告诉你他这次修改了多少字节的数据，如下所示他的格式：

redo log block

redolog 也不是一条一条的直接就写入到磁盘上的日志文件里去，MySQL内有一个数据结构，叫做 redo log block，其实和数据页差不多，就像数据存放在数据页一样，redo log也不是单行单行的写入日志文件的，它是用一个redo log block 来存放多个单行日志的。

一个redo log block是512字节，这个redo log block的512字节分为3个部分，一个是12字节的header块头，一个是496字节的body块体，一个是4字节的trailer块尾

而 12 字节的 header 又可以分4个部分：

1. 包括4个字节的 block no，就是块唯一编号；
2. 2个字节的 data length，就是block里写入了多少字节数据，初始值为12，随着往block中写入的redo日志越来也多，值也跟着增长，最后写满为512；
3. 2个字节的 first record group。这个是说每个事务都会有多个redo log，是一个redo log group，即一组redo log。那么在这个block里的第一组redo log的偏移量，就是这2个字节存储的；
4. 4个字节的 checkpoint on

简单的来说，就是一条一条的 redo log 日志先写入 redo log block 的内存中，当刷盘的时候，一次性将 redo log block 写入redo log 文件中。

redo log buffer

为了解决磁盘速度过慢的问题都会引入了 Buffer Pool。写入redo日志时也不能直接直接写到磁盘上，实际上在服务器启动时就向操作系统申请了一大片称之为 redo log buffer 的连续内存空间，这个空间默认是16M，可以通过innodb_log_buffer_size 设置大小，这片连续的内存空间，被划分成了若干个512字节大小的block。

写一条redo log的时候，就会先从第一个redo log block开始写入，写满了一个redo log block，就会继续写下一个redo log block，以此类推，直到所有的redo log block都写满，那有人问，写满了会怎么样，那此时必然会强制把redo log block刷入到磁盘中去。

值得注意的是，执行一个事务的过程中，每个事务会有多个增删改操作，那么就会有多个redolog，这多个redo log就是一组redo log，其实每次一组redo log都是先在别的地方暂存，然后都执行完了，再把一组redo log给写入到redo log buffer的block里去的。如果一组redo log实在是太多了，那么就可能会存放在两个redo log block中。

重做日志何时刷盘？

redo log buffer是内存的东西，它容易丢失啊，要将它持久化到 redo log file 才行啊，这个过程称为刷盘，那何时刷盘呢？

redo log buffer 刷盘时机：

1. 如果写入redo log buffer的日志已经占据了redo log buffer总容量的一半了，也就是超过了8MB的redo log在缓冲里了，此时就会把他们刷入到磁盘文件里去；
2. 一个事务提交的时候，必须把他的那些redo log所在的redo log block都刷入到磁盘文件里去，只有这样，当事务提交之后，他修改的数据绝对不会丢失，因为redo log里有重做日志，随时可以恢复事务做的修改；
3. 后台线程定时刷新，有一个后台线程每隔1秒就会把redo log buffer里的redo log block刷到磁盘文件里去；
4. MySQL关闭的时候，redo log block都会刷入到磁盘里去；
5. 将某个脏页刷新到磁盘前，会保证先将该脏页对应的 redo 日志刷新到磁盘中；

上面说的第一种情况其实是不常见的，第二种情况是比较常见的，往往redo log刷盘都是以一个短事务提交时候发生的，第三种情况就是后台线程每秒自动刷新redo log到磁盘去，假设没有别的情况触发，后台线程自己都会不停的刷新redo log到磁盘。

但是不管怎么说，主要是保证一个事务执行的时候，redo log都进入redo log buffer，提交事务的时候，事务对应的redo log必须是刷入磁盘文件，接着才算是事务提交成功，否则事务提交就是失败，保证这一点，就能确保事务提交之后，数据不会丢，有redo log在磁盘里就行了。

那是不是真的就不会丢了？

InnoDB 对于数据文件和日志文件的刷盘遵守WAL（write ahead redo log）和 Force-log-at-commit 两种规则，二者保证了事务的持久性。

• WAL 要求数据的变更写入到磁盘前，首先必须将内存中的日志写入到磁盘；
• Force-log-at-commit 要求当一个事务提交时，所有产生的日志都必须刷新到磁盘上，如果日志刷新成功后，缓冲池中的数据刷新到磁盘前数据库发生了宕机，那么重启时，数据库可以从日志中恢复数据。

如下图所示，InnoDB 在缓冲池中变更数据时，会首先将相关变更写入重做日志缓冲中，然后再按时（比如每秒刷新机制）或者当事务提交时写入磁盘，这符合 Force-log-at-commit 原则；
当重做日志写入磁盘后，缓冲池中的变更数据才会依据 checkpoint 机制写入到磁盘中，这符合 WAL 原则。

但是要注意的一点是：在 checkpoint 择时机制中，就有重做日志文件写满的判断，所以，如果重做日志文件太小，经常被写满，就会频繁导致 checkpoint 将更改的数据写入磁盘，导致性能抖动。

那按照上面两个规则就能确保数据不丢了吗？其实并不是， 你别忘了还有一个 os cache (操作系统缓存)。 操作系统的文件系统是带有缓存的，当 InnoDB 向磁盘写入数据时，有可能只是写入到了文件系统的缓存中，没有真正的“落袋为安”。

所以，InnoDB 的 innodb_flush_log_at_trx_commit 属性可以控制每次事务提交时 InnoDB 的行为。

• 当属性值为0时，事务提交时，不会对重做日志进行写入操作，而是等待主线程按时写入；

• 当属性值为1时，事务提交时，会将重做日志写入文件系统缓存，并且调用文件系统的 fsync ，将文件系统缓冲中的数据真正写入磁盘存储，确保不会出现数据丢失；

• 当属性值为2时，事务提交时，也会将日志文件写入文件系统缓存，但是不会调用fsync，而是让文件系统自己去判断何时将缓存写入磁盘。

日志的刷盘机制如下图所示：

Innodb_flush_log_at_commit 是 InnoDB 性能调优的一个基础参数，涉及 InnoDB 的写入效率和数据安全。

• 当参数数值为0时，写入效率最高，但是数据安全最低；
• 参数值为1时，写入效率最低，但是数据安全最高；
• 参数值为2时，二者都是中等水平，一般建议将属性值设置为1，以获得较高的安全性，而且也只有设置为1，才能保证事务的持久性。

redo log 文件

redolog buffer本质上是一片连续的内存空间，被划分成了若干个512字节大小的block。将redolog buffer中的redo日志刷新到磁盘的本质就是把block的镜像写入日志文件中，所以redo日志文件其实也是由若干个512字节大小的block组成。

默认情况下，redo log都会写入一个目录中的文件里，这个目录可以通过show variables like 'datadir'来查看，可以通过innodb_log_group_home_dir参数来设置这个目录的。

然后redo log 是有多个的，写满了一个就会写下一个redo log，而且可以限制redo log文件的数量，通过innodb_log_fifile_size可以指定每个redo log文件的大小，默认是48MB，通过innodb_log_fifiles_in_group可以指定日志文件的数量，默认就2个。

所以默认情况下，目录里就两个日志文件，分别为ib_logfifile0和ib_logfifile1，每个48MB，最多就这2个 日志文件，就是先写第一个，写满了写第二个。如果第二个也写满就覆盖第一个日志文件循环写，mysql默认保留了最近的96MB的redo log，不过这其实已经很多了，毕竟redo log真的很小，一条通常就几个字节到几十个字节不等，96MB足够你存储上百万条redo log

redo log 和 binlog

MySQL 整体来看，可以分成两块：
一块是 Server 层，它主要做的是 MySQL 功能层面的事情；
另外一块是引擎层，负责存储相关的具体事宜, redo log 是 InnoDB 引擎特有的日志，而 Server 层也有自己的日志，称为 binlog（归档日志）。

备注：MySQL体系结构可以参考这篇文章：MYSQL进阶之体系结构和InnoDB存储引擎

那为啥有两份日志：
因为最开始 MySQL 里并没有 InnoDB 引擎，MySQL 自带的引擎是 MyISAM，但是 MyISAM 没有 crash-safe 的能力，binlog 日志只能用于归档。而 InnoDB 是另一个公司以插件形式引入 MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系统——也就是 redo log 来实现 crash-safe 能力。

两种日志不同点：

1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。

2. redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。

3. redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

了解了概念，再来看看执行器和 InnoDB 引擎在执行 update T set c=c+1 where ID=2; 这条语句时内部流程:

1. 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。

2. 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。

3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。

4. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。

5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

从上面流程图可以知道，redo log 的写入拆成了两个步骤：prepare 和 commit，这就是"两阶段提交"。

两阶段提交

为什么必须有“两阶段提交”呢？这是为了让两份日志之间的逻辑一致。这样不好理解，那就假设没有两阶段提交的话会怎样？

由于 redo log 和 binlog 是两个独立的逻辑，如果不用两阶段提交，要么就是先写完 redo log 再写 binlog，或者采用反过来的顺序。我们看看这两种方式会有什么问题。

还是这条语句： update T set c=c+1 where ID=2;

假设当前 ID=2 的行，字段 c 的值是 0，再假设执行 update 语句过程中在写完第一个日志后，第二个日志还没有写完期间发生了 crash，会出现什么情况呢？

1. 先写 redo log 后写 binlog。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于redo log 写完了，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。
   但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。
   所以，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。

2. 先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1”这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同。

可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。

常见问题

问题：redo log 一般设置多大？

答：redo log 太小的话，会导致很快就被写满，然后不得不强行刷 redo log，这样 WAL 机制的能力就发挥不出来了。所以，如果是现在常见的几个 TB 的磁盘的话，直接将 redo log 设置为 4 个文件、每个文件 1GB 吧。

问题：redo log 和 binlog 是怎么关联起来的?

回答：它们有一个共同的数据字段，叫 XID。崩溃恢复的时候，会按顺序扫描 redo log：

• 如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；
• 如果碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务。

问题：不用两阶段提交，直接 redo log 写完，再写 binlog。崩溃恢复的时候，必须得两个日志都完整才可以，这样不可以吗？

回答：其实，两阶段提交是经典的分布式系统问题，并不是 MySQL 独有的。

如果要举一个场景来说明这么做的必要性的话，那就是事务的持久性问题。

对于 InnoDB 引擎来说，如果 redo log 提交完成了，事务就不能回滚（如果这还允许回滚，就可能覆盖掉别的事务的更新）。而如果 redo log 直接提交，然后 binlog 写入的时候失败，InnoDB 又回滚不了，数据和 binlog 日志又不一致了。

参考资料

《从零开始带你成为MySQL实战优化高手》
《MySQL技术内幕-InnoBD存储引擎》
《MySQL实战45讲》