MySQL重做日志（redo log）总结

目录

一、redo log的概念

二、redo log的作用

三、redo log的组成

四、redo log的工作原理

五、redo log的相关参数

六、redo log与undo log比较

七、redo log与二进制日志比较

附录：参考资料

---

一、redo log的概念

redo log，重做日志，也叫重放日志。和undo log回滚日志一样，都是在数据库发生意外时用来进行数据恢复的，通过前面一篇文章对undo log的总结，我们都知道undo log记录的是数据更新前的样子，主要保证事务的原子性；而redo log则记录的是事务执行过程中的修改情况，redo log主要保证事务的持久性。

当数据库对数据做修改的时候，需要把数据页从磁盘读到buffer pool中，然后在buffer pool中进行修改，那么这个时候buffer pool中的数据页就与磁盘上的数据页内容不一致，称buffer pool的数据页为dirty page 脏数据，如果这个时候发生非正常的DB服务重启，那么这些数据还没在内存，并没有同步到磁盘文件中（注意，同步到磁盘文件是个随机IO），也就是会发生数据丢失，如果这个时候，能够在有一个文件，当buffer pool 中的数据页变更结束后，把相应修改记录记录到这个文件（注意，记录日志是顺序IO），那么当DB服务发生crash，进行恢复DB的时候，可以根据这个文件的记录内容，重新持久化刷新到磁盘文件，保持数据的一致性。

这个文件其实就是redo log ，用于记录数据修改后的记录，顺序记录，主要用于数据的持久化操作。

二、redo log的作用

• 1、保证事务的持久性

如果buffer pool缓冲池中的脏页【脏数据】还没有进行刷盘的时候，此时数据库发生crash，重启服务后，我们可以通过redo log日志找到需要重放到磁盘文件的那些数据记录。

• 2、提高事务提交的速度

buffer pool缓冲池中的数据直接刷新到磁盘，是一个随机IO，效率较差，而把buffer pool中的数据记录到redo log，是一个顺序IO，可以提高事务提交的速度。例如：

我们执行了一条更新语句：

update user set name = 'lisi' where id = 1   --更新前name = 'zhangsan'

此时redo log就会用来存在name = 'lisi'这条更新后的新纪录，如果在刷盘时发生异常，我们可以通过redo log找到这条记录，然后进行重放操作，以保证事务的持久性。

三、redo log的组成

redo log由两部分组成：

• redo log buffer日志缓存

重做日志缓存(redo log buffer)存在于内存中，容易发生丢失。

• redo log file日志文件

重做日志文件(redo log file)存在于磁盘中，不容易发生丢失。

从redo log buffer写日志到磁盘的redo log file中，过程如下： 

为了确保每次日志都能写入到事务日志文件中，在每次将log buffer中的日志写入日志文件的过程中都会调用一次操作系统的fsync操作(即fsync()系统调用)。因为MariaDB/MySQL是工作在用户空间的，MariaDB/MySQL的log buffer处于用户空间的内存中。要写入到磁盘上的log file中(redo:ib_logfileN文件,undo:share tablespace或.ibd文件)，中间还要经过操作系统内核空间的os buffer，调用fsync()的作用就是将OS buffer中的日志刷到磁盘上的log file中。

四、redo log的工作原理

和undo log相反，redo log记录的是新数据的备份。在事务提交前，只要将redo log持久化即可，

不需要将数据持久化，不需要将数据持久化，不需要将数据持久化，重要的事情说三遍！。当系统崩溃时，虽然数据没有持久化，但是redo log已经持久化到磁盘中，系统可以根据redo log的内容，将所有数据恢复到最新的状态。

同样，通过一张图来理解redo log的工作原理。

下面描述一下redo事务的简化过程。

 假设有A、B两个数据，值分别为1,2，开始一个事务，事务的操作内容为：把1修改为3，2修改为4，那么实际的记录如下（简化）：

•   A. 事务开始.
•   B. 记录A=1到undo log.
•   C. 修改A=3.
•   D. 记录A=3到redo log.
•   E. 记录B=2到undo log. -------记录undo log回滚日志
•   F. 修改B=4. -------修改数据
•   G. 记录B=4到redo log. -------记录redo log重做日志
•   H. 将redo log写入磁盘。 -------redo log刷盘持久化
•   I. 事务提交 -------提交事务

如上过程，我们可以总结出来undo + redo事务的特点：

• A. 为了保证持久性，必须在事务提交前将redo log日志持久化。
• B. 数据不需要在事务提交前写入磁盘，而是缓存在内存中。
• C. redo log保证事务的持久性。
• D. undo log保证事务的原子性。
• E. 数据必须要晚于redo log写入持久存储。

五、redo log的相关参数

• innodb_flush_log_at_trx_commit

控制commit动作是否刷新log buffer到磁盘。该变量有3种值：0、1、2，默认为1。

1、innodb_flush_log_at_trx_commit=0【延迟写】：事务提交时不会将log buffer中日志写入到os buffer，然后每秒调用fsync()写入到log file on disk磁盘文件中。

这种情况下如果系统崩溃，会丢失1秒钟的数据。

2、innodb_flush_log_at_trx_commit=1【实时写，实时刷】：事务每次提交，会保存到log buffer，接着保存到os buffer操作系统缓存，并调用fsync()刷到log file on disk磁盘文件中。

这种方式即使系统崩溃也不会丢失任何数据，但是因为每次提交都写入磁盘，IO的性能较差。

3、innodb_flush_log_at_trx_commit=2【实时写，延迟刷】：每次事务提交，数据不写到log buffer，仅写入到os buffer，然后是每秒调用fsync()将os buffer中的日志写入到log file on disk磁盘文件中。

如下图：

正常情况下，设置参数值为0或者2能提供插入的效率，但在故障的时候可能会丢失1秒钟数据。并且参数值为2和0的时候差距并不大，因为它们都是每秒从os buffer刷到磁盘，它们之间的时间差体现在log buffer刷到os buffer上。因为将log buffer中的日志刷新到os buffer只是内存数据的转移，并没有太大的开销，所以每次提交和每秒刷入差距并不大。但值为1的性能却会差很多。

• innodb_log_buffer_size

指定 log buffer【redo log缓存区】的大小，默认8M。延迟事务日志写入磁盘，把redo log 放到该缓冲区，然后根据 innodb_flush_log_at_trx_commit参数的设置，再把日志从buffer 中flush 到磁盘中。

• innodb_log_file_size

指定事务日志的大小，默认5M。

• innodb_log_files_group =2

log group表示的是redo log group，一个组内由多个大小完全相同的redo log file组成。innodb_log_files_group指定事务日志组中的事务日志文件个数，默认2个，最大是100个。命名方式如：ib_logfile0，iblogfile1... iblogfilen。

在innodb将log buffer中的redo log block刷到这些log file中时，会以追加写入的方式循环轮训写入。即先在第一个log file（即ib_logfile0）的尾部追加写，直到满了之后向第二个log file（即ib_logfile1）写。当第二个log file满了会清空一部分第一个log file继续写入。

• innodb_log_group_home_dir =./

指定事务日志组路径，当前目录表示数据目录。

六、redo log与undo log比较

• 1、undo log和redo logo都是InnoDB的功能，都是事务日志。

• 2、redo log通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)。
• 3、undo log用来回滚行记录到某个版本。undo log一般是逻辑日志，根据每行记录进行记录。
• 4、undo log保证事务的原子性，而redo log则是保证事务的持久性。undo log在InnoDB中用来实现MVCC多版本控制，执行rollback操作时，undo log可以作为事务回滚的快照读参考，而redo log是备份的最新数据位置，系统冗机时，只要重启mysql服务，就可以将未持久保存的数据持久到磁盘。

七、redo log与二进制日志比较

• 1、redo log是MySQL InnoDB存储引擎产生的，只记录该存储引擎中表的修改，而二进制日志是在数据库层面产生的，所有存储引擎对数据库进行修改都会产生二进制日志。
• 2、二进制日志记录的是对应的SQL，比如记录的该行数据每一列的值是多少多少，而redo log记录的则是物理数据页的修改记录。
• 3、redo log记录的是物理格式的日志，记录了对页的操作，而binlog记录的是逻辑日志，记录的是对应的SQL。
• 4、redo log记录的是数据页的物理变化，因此恢复的时候速度比二进制日志要快很多。另外，redo log具有幂等性，所以多次操作得到同一结果的行为在日志中只记录一次。而二进制日志不具有幂等性，多次操作会全部记录下来，在恢复的时候会多次执行二进制日志中的记录，速度就慢得多。例如，某记录中id初始值为2，通过update将值设置为了3，后来又设置成了2，在事务日志中记录的将是无变化的页，根本无需恢复；而二进制会记录下两次update操作，恢复时也将执行这两次update操作，速度比事务日志恢复更慢。

• 5、二进制日志在提交的时候一次性写入，一次提交对应一条记录，而redo log中是记录的物理页的修改，redo log文件中同一个事务可能多次记录，最后一个提交的事务记录会覆盖所有未提交的事务记录。举个例子，一个事务中插入10万条记录：

insert into user(name, age) values('zs', 20);
insert into user(name, age) values('ls', 30);
//.....插入十万条记录

在这个过程中，MySQL会一直不断的往redo log顺序记录，而binary log则不会记录，直到commit事务，才会一次性写入到bin log日志中。

附录：参考资料

https://www.cnblogs.com/f-ck-need-u/p/9010872.html#auto_id_11

https://www.cnblogs.com/wyy123/p/7880077.html

《MySQL技术内幕（第5版）》