当前位置：首页 > news >正文

【MySQL进阶之路 | 高级篇】redo日志和undo日志

news 来源：原创 2024/9/22 17:37:41

1. 前言

事务有四种特性：原子性，一致性，隔离性和持久性。那么事务的四种特性到底是基于什么机制实现呢？

事务的隔离性由锁机制实现。
而事务的原子性，一致性和持久性由事务的redo日志和undo日志来保证。

REDO LOG称为重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。

UNDO LOG称为回滚日志，回滚行记录到某个特定版本，用来保证事务的原子性，一致性。

REDO和UNDO都可以视为一种恢复操作但是

redo log：是存储引擎层生成的日志，记录的是物理级别上的页修改操作，比如页号xxx，偏移量yyy写入了'zzz'数据。主要是为了保证数据的可靠性。
undo log：是存储引擎层生成的日志，记录的是逻辑操作的日志，比如对某一行数据进行了INSERT语句操作，那么undo log就记录一条与之相反的DELETE操作。主要用于事务的回滚（undo log记录的是每个修改操作的逆操作）和一致性非锁定读（undo log回滚行记录到某种特定的版本--MVCC，即多版本并发控制）。

2. redo日志

InnoDB存储引擎是以页为单位来管理存储空间的。在真正访问到页面之前，需要把在磁盘上的页缓存到内存中的Buffer Pool之后才可以访问。所有的变更都必须先更新缓冲池中的数据，然后缓冲池的脏页会会以一定频率被刷入磁盘（checkPoint机制），通过缓冲池来优化CPU和磁盘之间的鸿沟，这样就可以保证整体的性能不会下降的太快。

2.1 为什么需要REDO日志

一方面，缓冲池可以帮助我们消除CPU和磁盘之间的鸿沟，checkPoint机制可以保证数据的最终落盘，然而由于checkPoint机制并不是每次变更的时候就触发的，而是master线程隔一段时间去处理的。所以最坏的情况就是事务提交后，刚写完缓冲池，数据库宕机，那么这段数据就是丢失的，无法恢复。

另一方面，事务包含持久性的特性，就是说对于一个已经提交的事务，在事务提交后即使系统发生了崩溃，这个事务对数据库中所作的更改也不能丢失。

那么如何保证这个持久性呢？一个简单的做法：在事务提交完成之前把事务所修改的所有页面都刷新到磁盘上，但这个简单粗暴的做法有一些问题：

修改量与刷新磁盘工作量严重不成比例：有时候我们仅仅修改了某个页面的一个字节，但是我们知道在InnoDB中是以页为单位来进行磁盘IO的，页就是说我们在该事务提交时不得不将一个完整的页面从内存中刷新到磁盘上，我们又知道一个页面的默认是16KB大小，只修改一个字节就要刷新16KB的数据到内存上显然是大题小作。
随机IO刷新较慢：一个事务可能包含很多语句，即使是一条语句也可能修改很多页面，假如该事务修改的这些页面可能并不相邻，这就意味着在将某个事务修改的buffer pool中的页面刷新到磁盘上时，需要进行很多的随机IO，随机IO比顺序IO要慢。

另一个解决的思路：我们只是想让已经提交了的事务对数据库中数据所做的修改永远生效，即使后来系统崩溃，在重启后也能把这种修改恢复出来。所以我们其实也没必要在每次事务提交时就把改事务在内存中修改的全部页面刷新到磁盘上，只需要把修改了哪些东西记录一下就好了。比如，某个事物将系统表空间中第10号页面中偏移量为100处的那个字节的值1改成值2，我们只需要记录一下：将第0号表空间的第10个页面的偏移量为100处的值更新为2。

InnoDB引擎的事物采用了WAL技术（Write-Ahead Logging），这种技术的思想就是先写日志，再写磁盘，只有日志写入成功，才算事务提交成功，这里的日志就是redo log。当发生宕机且数据未刷到磁盘的时候，可以通过redo log来恢复，保证ACID中的D，这就是redo log的作用。

2.2 REDO日志的好处，特性

1). 好处

redo日志降低了刷盘频率。
redo日志占用的空间非常小。

存储表空间ID，页号，偏移量以及需要更新的值，所需的存储空间是很小的，刷盘快。

2). 特点

redo日志是顺序写入磁盘的。

在执行事务的过程，每执行一条语句，就可能产生若干条redo日志，这些日志是按照产生的顺序写入磁盘的。也就是使用顺序IO，效率比随机IO快。

事务执行过程中，redo log不断记录

redo log跟bin log的区别，redo log是存储引擎层产生的，而bin log是数据库层产生的。假设一个事务，对表做10万行记录插入，在这个过程中，一直不断的往redo log顺序记录，而bin log不会记录，直到这个事务被提交，才会一次写入到bin log文件中。

2.3 redo的组成

redo log可以简单分为以下两个部分：

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

在服务器启动时就向操作系统申请了一大片空间称之为redo log buffer的连续内存空间，翻译成中文就是redo日志缓冲区。这片内存空间被划分为若干个连续的redo log block。一个redo log block占用512字节大小。

参数设置：innodb_log_buffer_size：默认大小16M，最大值是4096M，最小为1M。

重做日志文件（redo log file），保存在硬盘中，是持久的。ib_logfile0和ib_logfile1是REDO日志。

2.4 redo的整体流程

以一个更新事务为例，redo log流转流程，如下：

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

2.5 redo的刷盘策略

注意，redo log buffer刷盘到redo log file的过程并不是真正的刷到磁盘中去，只是刷入到文件系统缓存（page cache）中去（这是现代操作系统为了提高文件写入效率做的一个优化），真正的写入会交给系统自己来决定（比如page cache足够大了）。那么对于InnoDB来说就存在一个问题，如果交给系统来同步，同样如果系统宕机了，那么数据也丢失了。

针对这种情况，InnoDB给出了innodb_flush_log_at_trx_commit参数，该参数控制commit提交事务时，如何将redo log buffer中的日志刷新到redo log file中。它支持三种策略：

设置为0：表示每次事务提交时不进行刷盘操作，（xito默认master thread每隔1s进行一次重做日志的同步）
设置为1：表示每次事务提交的时都将进行同步，刷盘操作（默认值）
设置为2：表示每次事务提交时都只把redo log buffer内容写入到page cache中，不进行同步。由os自己决定什么时候同步到磁盘文件。

查看变量：show variables like 'innodb_flush_log_at_trx_commit';

另外，InnoDB存储引擎有一个后台线程，每隔1s，就会把redo log buffer中的内容写到文件系统缓存（page cache），然后调用刷盘操作。

2.6 不同刷盘策略演示

1). innodb_flush_log_at_trx_commit=1

这种情况只要是1，redo log记录就一定在硬盘里，不会有任何数据的丢失。
如果事务执行期间MySQL挂了或宕机，在部分日志丢了，但事务并没有提交，所以日志丢了也不会有损失。可以保证ACID的D，数据绝对不会丢失，但是效率最差的。
建议使用默认值，虽然操作系统宕机的概率理论小于数据库宕机的概率，但是一般使用的事务，那么数据库的安全相对来说重要一些。

2). innodb_flush_log_at_trx_commit=2；

当innodb_flush_log_at_trx_commit=2时，只要事务提交成功，redo log buffer的内容只是写入到文系统缓存（page cache）。如果仅仅是MySQL挂了不会有任何数据的丢失，但是操作系统宕机肯恩那个会有1s数据的丢失。这种情况无法满足ACID中的D。但是数值2肯定是效率最高的。

3). innodb_flush_log_at_trx_commit=0