浅析MySQL事务中的redo与undo

咱们都知道事务有4种特性：原子性、一致性、隔离性和持久性，在事务中的操做，要么所有执行，要么所有不作，这就是事务的目的。事务的隔离性由锁机制实现，原子性、一致性和持久性由事务的redo 日志和undo 日志来保证。因此本篇文章将讨论关于事务中的redo和undo的几个问题：

• redo 日志与undo日志分别是什么？
• redo 如何保证事务的持久性？
• undo log 是不是redo log的逆过程？

redo log

Redo 的类型

重作日志(redo log)用来保证事务的持久性，即事务ACID中的D。实际上它能够分为如下两种类型：

• 物理Redo日志
• 逻辑Redo日志

在InnoDB存储引擎中，大部分状况下 Redo是物理日志，记录的是数据页的物理变化。而逻辑Redo日志，不是记录页面的实际修改，而是记录修改页面的一类操做，好比新建数据页时，须要记录逻辑日志。关于逻辑Redo日志涉及更加底层的内容，这里咱们只须要记住绝大数状况下，Redo是物理日志便可，DML对页的修改操做，均须要记录Redo.

Redo 的做用

Redo log的主要做用是用于数据库的崩溃恢复

Redo 的组成

Redo log能够简单分为如下两个部分：

• 一是内存中重作日志缓冲 (redo log buffer),是易失的，在内存中
• 二是重作日志文件 (redo log file)，是持久的，保存在磁盘中

何时写Redo?

上面那张图简单地体现了Redo的写入流程，这里再细说下写入Redo的时机：

• 在数据页修改完成以后，在脏页刷出磁盘以前，写入redo日志。注意的是先修改数据，后写日志
• redo日志比数据页先写回磁盘
• 汇集索引、二级索引、undo页面的修改，均须要记录Redo日志。

Redo的总体流程

下面以一个更新事务为例，宏观上把握redo log 流转过程，以下图所示：

• 第一步：先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝
• 第二步：生成一条重作日志并写入redo log buffer，记录的是数据被修改后的值
• 第三步：当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log file采用追加写的方式
• 第四步：按期将内存中修改的数据刷新到磁盘中

redo如何保证 事务的持久性？

InnoDB是事务的存储引擎，其经过Force Log at Commit 机制实现事务的持久性，即当事务提交时，先将 redo log buffer 写入到 redo log file 进行持久化，待事务的commit操做完成时才算完成。这种作法也被称为 Write-Ahead Log(预先日志持久化)，在持久化一个数据页以前，先将内存中相应的日志页持久化。

为了保证每第二天志都写入redo log file，在每次将redo buffer写入redo log file以后，默认状况下，InnoDB存储引擎都须要调用一次 fsync操做,由于重作日志打开并无 O_DIRECT选项，因此重作日志先写入到文件系统缓存。为了确保重作日志写入到磁盘，必须进行一次 fsync操做。fsync是一种系统调用操做，其fsync的效率取决于磁盘的性能，所以磁盘的性能也影响了事务提交的性能，也就是数据库的性能。
(O_DIRECT选项是在Linux系统中的选项，使用该选项后，对文件进行直接IO操做，不通过文件系统缓存，直接写入磁盘)

上面提到的Force Log at Commit机制就是靠InnoDB存储引擎提供的参数 innodb_flush_log_at_trx_commit来控制的，该参数能够控制 redo log刷新到磁盘的策略，设置该参数值也能够容许用户设置非持久性的状况发生，具体以下：

• 当设置参数为1时，（默认为1），表示事务提交时必须调用一次 fsync 操做，最安全的配置，保障持久性
• 当设置参数为2时，则在事务提交时只作 write 操做，只保证将redo log buffer写到系统的页面缓存中，不进行fsync操做，所以若是MySQL数据库宕机时 不会丢失事务，但操做系统宕机则可能丢失事务
• 当设置参数为0时，表示事务提交时不进行写入redo log操做，这个操做仅在master thread 中完成，而在master thread中每1秒进行一次重作日志的fsync操做，所以实例 crash 最多丢失1秒钟内的事务。（master thread是负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性）

fsync和write操做其实是系统调用函数，在不少持久化场景都有使用到，好比 Redis 的AOF持久化中也使用到两个函数。fsync操做 将数据提交到硬盘中，强制硬盘同步，将一直阻塞到写入硬盘完成后返回，大量进行fsync操做就有性能瓶颈，而write操做将数据写到系统的页面缓存后当即返回，后面依靠系统的调度机制将缓存数据刷到磁盘中去,其顺序是user buffer——> page cache——>disk。

除了上面谈到的Force Log at Commit机制保证事务的持久性，实际上重作日志的实现还要依赖于mini-transaction。

Redo在InnoDB中是如何实现的？与mini-transaction的联系？

Redo的实现实则跟mini-transaction紧密相关，mini-transaction是一种InnoDB内部使用的机制，经过mini-transaction来保证并发事务操做下以及数据库异常时数据页中数据的一致性，但它不属于事务。

为了使得mini-transaction保证数据页数据的一致性，mini-transaction必须遵循如下三种协议：

• The FIX Rules
• Write-Ahead Log
• Force-log-at-commit

The FIX Rules

修改一个数据页时须要得到该页的x-latch(排他锁)，获取一个数据页时须要该页的s-latch(读锁或者称为共享锁) 或者是 x-latch，持有该页的锁直到修改或访问该页的操做完成。

Write-Ahead Log

在前面阐述中就提到了Write-Ahead Log(预先写日志)。在持久化一个数据页以前，必须先将内存中相应的日志页持久化。每一个页都有一个LSN(log sequence number)，表明日志序列号，（LSN占用8字节，单调递增), 当一个数据页须要写入到持久化设备以前，要求内存中小于该页LSN的日志先写入持久化设备

那为何必需要先写日志呢？可不能够不写日志，直接将数据写入磁盘？原则上是能够的，只不过会产生一些问题，数据修改会产生随机IO，但日志是顺序IO，append方式顺序写，是一种串行的方式，这样才能充分利用磁盘的性能。

Force-log-at-commit

这一点也就是前文提到的如何保证事务的持久性的内容，这里再次总结一下，与上面的内容相呼应。在一个事务中能够修改多个页，Write-Ahead Log 能够保证单个数据页的一致性，可是没法保证事务的持久性，Force-log-at-commit 要求当一个事务提交时，其产生全部的mini-transaction 日志必须刷新到磁盘中，若日志刷新完成后，在缓冲池中的页刷新到持久化存储设备前数据库发生了宕机，那么数据库重启时，能够经过日志来保证数据的完整性。

重作日志的写入流程

上图表示了重作日志的写入流程，每一个mini-transaction对应每一条DML操做，好比一条update语句，其由一个mini-transaction来保证，对数据修改后，产生redo1，首先将其写入mini-transaction私有的Buffer中，update语句结束后，将redo1从私有Buffer拷贝到公有的Log Buffer中。当整个外部事务提交时，将redo log buffer再刷入到redo log file中。

undo log

undo log的定义

undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚以前的操做，须要将以前的操做都记录下来，而后在发生错误时才能够回滚。

undo log的做用

undo是一种逻辑日志，有两个做用：

• 用于事务的回滚
• MVCC

关于MVCC(多版本并发控制)的内容这里就很少说了，本文重点关注undo log用于事务的回滚。

undo日志，只将数据库逻辑地恢复到原来的样子，在回滚的时候，它其实是作的相反的工做，好比一条INSERT ，对应一条 DELETE，对于每一个UPDATE,对应一条相反的 UPDATE,将修改前的行放回去。undo日志用于事务的回滚操做进而保障了事务的原子性。

undo log的写入时机

• DML操做修改聚簇索引前，记录undo日志
• 二级索引记录的修改，不记录undo日志

须要注意的是，undo页面的修改，一样须要记录redo日志。

undo的存储位置

在InnoDB存储引擎中，undo存储在回滚段(Rollback Segment)中,每一个回滚段记录了1024个undo log segment，而在每一个undo log segment段中进行undo 页的申请，在5.6之前，Rollback Segment是在共享表空间里的，5.6.3以后，可经过 innodb_undo_tablespace设置undo存储的位置。

undo的类型

在InnoDB存储引擎中，undo log分为：

• insert undo log
• update undo log

insert undo log是指在insert 操做中产生的undo log，由于insert操做的记录，只对事务自己可见，对其余事务不可见。故该undo log能够在事务提交后直接删除，不须要进行purge操做。

而update undo log记录的是对delete 和update操做产生的undo log，该undo log可能须要提供MVCC机制，所以不能再事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。

补充：purge线程两个主要做用是：清理undo页和清除page里面带有Delete_Bit标识的数据行。在InnoDB中，事务中的Delete操做实际上并非真正的删除掉数据行，而是一种Delete Mark操做，在记录上标识Delete_Bit，而不删除记录。是一种"假删除",只是作了个标记，真正的删除工做须要后台purge线程去完成。

undo log 是不是redo log的逆过程？

undo log 是不是redo log的逆过程？其实从前文就能够得出答案了，undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来的样子，而redo log是物理日志，记录的是数据页的物理变化，显然undo log不是redo log的逆过程。

redo & undo总结

下面是redo log + undo log的简化过程，便于理解两种日志的过程：

假设有A、B两个数据，值分别为1,2.
1. 事务开始
2. 记录A=1到undo log
3. 修改A=3
4. 记录A=3到 redo log
5. 记录B=2到 undo log
6. 修改B=4
7. 记录B=4到redo log
8. 将redo log写入磁盘
9. 事务提交

实际上，在insert/update/delete操做中，redo和undo分别记录的内容都不同，量也不同。在InnoDB内存中，通常的顺序以下：

• 写undo的redo
• 写undo
• 修改数据页
• 写Redo

小结

本文分析了事务中的redo和undo日志，参考了一些资料书籍整理得出，可能有些地方表述的不清楚。若有不对之处，欢迎指出。

参考资料 & 鸣谢

• MySQL技术内幕：InnoDB存储引擎（第2版）
• MySQL内核：InnoDB存储引擎 卷1
• InnoDB 日志/回滚段/崩溃恢复实现详解
• MySQL · 引擎特性 · InnoDB redo log漫游
• MySQL的undo,redo,二阶段提交思惟导图