本文深入探讨MySQL的redo log和undo log，解释它们在事务原子性、一致性和持久性中的角色。redo log记录数据页的物理修改，用于恢复提交后的数据；undo log则记录数据的逻辑变化，用于事务回滚。文章讨论了redo log与二进制日志的区别、重做日志的类型及其作用，并详细阐述了undo log的存储位置和类型。最后，通过一个事务例子总结了redo log和undo log的整个流程。
写在前面
本文是对于网上各个对redo和undo log日志解析的总结，参考文章列表在最后。
事务的4大特性：原子性、一致性、隔离性和持久性。
事务的隔离性由锁机制实现。
原子性、一致性和持久性由事务的redo 日志和undo 日志来保证。
redo log：物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成什么样子，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)。
undo log:用来回滚行记录到某个版本。undo log一般是逻辑日志，根据每行数据的修改前数据和修改操作记录。
redo log
redo log和二进制日志的区别
redo log不是二进制日志。虽然二进制日志中也记录了innodb表的很多操作，也能实现重做的功能，但是它们之间有很大区别。
二进制日志是在存储引擎的上层产生的，不管是什么存储引擎，对数据库进行了修改都会产生二进制日志。而redo log是innodb层产生的，只记录该存储引擎中表的修改。并且二进制日志先于****redo log****被记录。
二进制日志记录逻辑性的语句。即便它是基于行格式的记录方式，其本质也还是逻辑的SQL设置，如该行记录的每列的值是多少。而redo log是在物理格式上的日志，它记录的是数据库中每个页的修改。
二进制日志只在每次事务提交的时候一次性写入缓存中的日志"文件"。而redo log在事务中就会产生，并且在对数据真正修改前先写入缓存中的redo log中，然后才对内存中的数据执行修改操作；而且保证在发出事务提交指令时，先向缓存中的redo log写入到redo log file中，redo log file 写入完成后才执行提交动作。
因为二进制日志只在提交的时候一次性写入，所以二进制日志中的记录方式和提交顺序有关，且一次提交对应一次记录。而redo log中是记录的物理页的修改，redo log file中同一个事务可能多次记录，最后一个提交的事务记录会覆盖所有未提交的事务记录。例如事务T1，可能在redo log中记录了 T1-1,T1- 2,T1-3，T1* 共4个操作，其中 T1* 表示最后提交时的日志记录，所以对应的数据页最终状态是 T1* 对应的操作结果。而且redo log是并发写入的，不同事务之间的不同版本的记录会穿插写入到redo log文件中，例如可能redo log的记录方式如下： T1-1,T1-2,T2-1,T2- 2,T2,T1-3,T1 。
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 log?
上面那张图简单地体现了Redo的写入流程，这里再细说下写入Redo的时机：
在数据页修改完成之后，在脏页刷出磁盘之前，写入redo日志。注意的是先修改数据，后写日志
redo日志比数据页先写回磁盘
聚集索引、二级索引、undo页面的修改，均需要记录Redo日志。
Redo的整体流程
下面以一个更新事务为例，宏观执行流程如下图所示：
1：将原始数据从磁盘中读入内存中，修改数据在内存中的拷贝
2：生成一条redo log并写入redo log buffer，记录的是数据被修改后的值
3：当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log file采用追加写的方式
4：定期将内存中修改的数据刷新到磁盘中
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操作,因为redo log并没有 O_DIRECT选项，所以redo log先写入到文件系统缓存。为了确保redo log写入到磁盘，必须进行一次 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 file操作，这个操作仅在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机制保证事务的持久性，实际上redo log的实现还要依赖于mini-transaction。
Redo在InnoDB中是如何实现的？与mini-transaction的联系？
Redo log的实现跟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
在持久化一个数据页之前，必须先将内存中相应的日志页持久化。每个页都有一个LSN(log sequence number)，代表日志序列号，(LSN占用8字节，单调递增), 当一个数据页需要写入到持久化设备之前，要求内存中小于该页LSN的日志先写入持久化设备。
那为什么必须要先写日志呢？可不可以不写日志，直接将数据写入磁盘？原则上是可以的，只不过会产生一些问题，数据修改会产生随机IO，但日志是顺序IO，append方式顺序写，是一种串行的方式，这样才能充分利用磁盘的性能。
Force-log-at-commit
在一个事务中可以修改多个页，Write-Ahead Log 可以保证单个数据页的一致性，但是无法保证事务的持久性，Force-log-at-commit 要求当一个事务提交时，其产生所有的mini-transaction 日志必须刷新到磁盘中，若日志刷新完成后，在缓冲池中的页刷新到持久化存储设备前数据库发生了宕机，那么数据库重启时，可以通过日志来保证数据的完整性。
redo log的写入流程
123.png
上图表示了redo log的写入流程，每个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
重点关注如何利用undo log进行事务回滚。
undo日志，只将数据库逻辑地恢复到原来的样子，在回滚的时候，它实际上是做的相反的工作，比如一条INSERT ，对应一条 DELETE，对于每个UPDATE,对应一条相反的 UPDATE,将修改前的行放回去。通过undo log进行事务回滚操作可以保障事务的原子性。
undo log的写入时机
DML操作修改聚簇索引前，记录undo log
二级索引记录的修改，不记录undo log
需要注意的是，undo log页面的修改，同样需要记录redo日志。
undo log的存储位置
在InnoDB存储引擎中，undo log存储在回滚段(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
参考：
扫一扫
810
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
