MySQL事务中的redo与undo

redo log

redo

重做日志（redo log）用来保证事务的持久性。实际上可以分为两种类型：

物理redo日志

逻辑redo日志

在InnoDB存储引擎中，大部分情况下redo是物理日志，记录的是数据页的物理变化。而逻辑redo日志，不是记录页面的实际修改，而是记录修改页面的一类操作，比如新建数据页时，需要记录逻辑日志。

大部分情况下，redo是物理日志，DML对页的修改操作，需要记录redo。

redo的作用

redo log 的主要作用是用于数据库的崩溃恢复

redo的组成

一是内存中重做日志缓冲（redo log buffer）,是易失的，在内存中

而是重做日志文件（redo log file），是持久的，保存在磁盘中

什么时候写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数据库宕机时，不会丢失事务，但os宕机则可能丢失事务。
当设置参数为0时，表示事务提交时不进行redo log操作这个操作仅在master thread中完成，而在master thread中每一秒进行一次重做日志的fsync操作，因此实例crash最多丢失1s内的事务。（master thread是负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性）
fsync和write操作实际上是系统调用函数，在很多持久化场景都有使用到，比如redis的AOF持久化中也使用到这两个函数。

fsync操作将数据提交到硬盘中，强制硬盘同步，将一直阻塞到写入硬盘完成后返回，大量进行fsync操作就有性能瓶颈，而

write操作将数据写到系统的页面缓存后立即返回，后面依靠系统的调度机制将缓存数据刷到磁盘中去，其顺序是usr buffer----->

page cache -------> disk

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（共享锁），持有该页的锁直到修改或访问该页的操作完成。

Write-Ahead Log

在前面阐述是提过Write-Ahead Log（预先写日志）。在持久化一个数据页之前，必须先将内存中相应的日志页持久化。每个页都有一个LSN(log sequence number),代表日志序列号，（LSN占用8字节，单调递增），当一个数据页需要写入持久化设备之前，要求内存中小于该页LSN的日志先写入持久化设备。写日志采用append方式顺序写，是一种串行的方式，比起随机写，顺序写更能充分利用磁盘的性能。

Force-log-at-commit

这一点也就是前文提到的ruhr保证事务的持久性的内容。在一个事务中可以修改多个页，write-Ahead Log可以保证单个数据页的一致性，但是无法保证事务的持久性，Force-log-at-commit要求当一个事务提交时，其产生所有的mini-transcation日志必须刷新到磁盘中，若日志刷新完成后，在缓冲池中的页刷新到持久化存储设备前数据库发生了宕机，那么数据库重启时，可以通过日志来保证数据的完整性。

重做日志的写入流程：

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

undo

undo log的定义

undo主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。

undo log的作用

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

• 用于事务的回滚
• MVCC

undol log的写入时机：

DML操作修改聚集索引前，记录undo日志
二级索引记录的修改，不记录undo日志
需要注意的是，undo页面的修改，同样需要记录redo日志

undo的存储位置

在InnoDB存储引擎中，undo存储在数据库内部的undo段（undo segment).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的逆过程。

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