MySQL各种“Buffer”之Log Buffer

上回书MySQL各种“Buffer”之Doublewrite Buffer首次提到Redo Log的概念，Redo Log是数据库体系架构中非常重要的一个模块，它能保证数据库的Crash-safe（崩溃恢复）的能力。而今天要介绍的Log Buffer正和Redo Log息息相关、密不可分。所以我们就来一起盘它。

（https://dev.mysql.com/doc/refman/5.7/en/innodb-architecture.html）

• 丁奇-极客时间APP-课程《MySQL实战45讲》
• 58沈剑-架构师之路-公众号文章《事务已提交，数据却丢了，赶紧检查下这个配置！！！| 数据库系列》

Redo Log介绍

Redo Log（重做日志）是MySQL中非常重要的日志模块，（MySQL官档https://dev.mysql.com/doc/refman/5.7/en/innodb-redo-log.html中给出的解释是：重做日志是一种基于磁盘的数据结构，用于在崩溃恢复期间纠正不完整事务写入的数据。在正常操作期间，重做日志对由SQL语句或低级API调用产生的更改表数据的请求进行编码。在初始化期间和接受连接之前，会自动重播在意外关闭之前未完成更新数据文件的修改），MySQL里经常说到的WAL技术（WAL的全称是Write-Ahead Logging），它的关键点就是日志先行（也称为写前日志，实际写数据之前，先把修改的数据记录到日志文之间中。即先写日志，再写磁盘），其实很多数据库软件设计的理念都是日志先行。（但是Redis的AOF（Append Only File）日志正好相反，它是写后日志，“写后”的意思是Redis的先执行命令，把数据写入内存，然后才记录日志），MySQL中日志先行的这个“日志”就是Redo Log。

Redo Log是InnoDB引擎特有的日志，而MySQL Server层也有自己的日志，称为binlog（不在我们本文的讨论范围，下一章我们就会见到它了，拭目以待吧）。正是因为有了Redo Log，才保证了InnoDB存储引擎的Crash-safe能力。

Redo Log是物理日志，记录的是“在某个数据页上做了什么修改（做了什么改动）”。一句话概括一下，Redo Log是为了保证已提交事务的ACID特性，同时能够提高数据库性能的技术。

SHOW VARIABLES LIKE '%innodb_log%';SHOW VARIABLES LIKE '%innodb_flush_log%';

从上面可以看出，Redo Log的相关参数还是很多的，所以我们拿重点的来说，其余参数一般为默认值，感兴趣的同学可移步MySQL官档（https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html）进行查阅。

• 参数：innodb_log_buffer_size

介绍：InnoDB用于写入磁盘上的日志文件的缓冲区的大小（以字节为单位）。这就是定义我们文章标题的Log Buffer大小的参数。随着32KB和64KBinnodb_page_size
值的引入，默认值从8MB更改为16MB。大型日志缓冲区使大型事务能够运行，而无需在事务提交之前将日志写入磁盘。因此，如果您有更新、插入或删除许多行的事务，则增大日志缓冲区可以节省磁盘 I/O。

• 参数：innodb_log_checksums

• 参数：innodb_log_file_size
• 参数：innodb_log_files_in_group

InnoDB的Redo Log是固定大小的，比如截图中的配置为一组3个文件，每个文件的大小是1GB，那么我们Redo Log就可以记录3 × 1G = 3G的记录。从头开始写，写到末尾就又回到开头循环写，就这样循环覆盖写，如下面这个图所示。

• 参数：innodb_flush_log_at_trx_commit

介绍：控制提交操作的严格ACID合规性与当与提交相关的I/O操作重新排列并批量完成时可能实现的更高性能之间的平衡。这个参数非常重要，后面的Log Buffer原理主要是关于这个参数的。设置的值不同会产生不同的效果，可设置的值可以是0、1或2。

Log Buffer工作原理

简单来说一下Redo Log的三层结构：

• 粉色部分：是InnoDB一项很重要的内存结构（In-Memory Structure），即我们的Log Buffer（日志缓冲区），这一层，是MySQL应用程序用户态控制。

• 黄色部分：操作系统文件系统的缓冲区（FS Page Cache），这一层，是操作系统OS内核态控制。

• 绿色部分：就是落盘的物理日志文件。

1、首先，事务提交的时候，会写入Log Buffer，这里调用的是MySQL自己的函数WriteRedoLog；

2、接着，只有当MySQL发起系统调用写文件write时，Log Buffer里的数据，才会写到FS Page Cache。注意，MySQL系统调用完write之后，就认为文件已经写完，如果不flush，什么时候落盘，是操作系统决定的；

3、最后，由操作系统（当然，MySQL也可以主动flush）将FS Page Cache里的数据，最终fsync到磁盘上；

• Q-1：操作系统为什么要缓冲数据到FS Page Cache里，而不直接刷盘呢？

A-1：这里就是将“每次写”优化为“批量写”，以提高操作系统性能。

• Q-2：数据库为什么要缓冲数据到Log Buffer里，而不是直接write呢？

A-2：这也是“每次写”优化为“批量写”思路的体现，以提高数据库性能。

• Q-3：Redo Log三层架构，MySQL做了一次批量写优化，OS做了一次批量写优化，确实能极大提升性能，但有什么副作用吗？

A-3：有优点，必有缺点。这个副作用，就是可能丢失数据：

①事务提交时，将Redo Log写入Log Buffer，就会认为事务提交成功；

②如果写入Log Buffer的数据，write入FS Page Cache之前，数据库崩溃，就会出现数据丢失；

③如果写入FS Page Cache的数据，fsync入磁盘之前，操作系统奔溃，也可能出现数据丢失；

（如上文所说，应用程序系统调用完write之后（不可能每次write后都立刻flush，这样写日志很蠢），就认为写成功了，操作系统何时fsync，应用程序并不知道，如果操作系统崩溃，数据可能丢失）

• 目前有三种策略，即对应可设置的值可以是0、1或2。

• 策略一：最佳性能（innodb_flush_log_at_trx_commit=0）

• 策略二：强一致（innodb_flush_log_at_trx_commit=1）

• 策略三：折衷（innodb_flush_log_at_trx_commit=2）

高并发业务，行业最佳实践，是使用第三种折衷配置（innodb_flush_log_at_trx_commit=2），这是因为：

1、配置为2和配置为0，性能差异并不大，因为将数据从Log Buffer拷贝到FS Page Cache，虽然跨越用户态与内核态，但毕竟只是内存的数据拷贝，速度很快；

2、配置为2和配置为0，安全性差异巨大，操作系统崩溃的概率相比MySQL应用程序崩溃的概率，小很多，设置为2，只要操作系统不奔溃，也绝对不会丢数据。

小结

今天理论的知识不是很多，下面简单做一下总结：

1、Redo Log（重做日志）是MySQL中非常重要的日志模块，是为了保证已提交事务的ACID特性、保证InnoDB存储引擎的Crash-safe能力，同时能够提高数据库性能的技术。它是循环覆盖写的物理日志。

2、Redo Log是一种顺序写，它有三层架构：①Log Buffer；②FS Page Cache；③Redo Log Files；

3、为了满足不用业务对于吞吐量与一致性的需求，MySQL事务提交时刷Redo Log有三种策略：

• innodb_flush_log_at_trx_commit=0，每秒write一次FS Page Cache，同时fsync刷磁盘，性能好；

• innodb_flush_log_at_trx_commit=1，每次都write入FS Page Cache，同时fsync刷磁盘，一致性好；

• innodb_flush_log_at_trx_commit=2，每次都write入FS Page Cache，每秒fsync刷磁盘，折衷；

4、高并发业务，行业内的最佳实践，是：innodb_flush_log_at_trx_commit=2。

今天主要讲解了Redo Log和MySQL InnoDB Log Buffer的工作原理，通过流程图的方式来说明Redo Log三种刷盘策略的工作流程，偏理论的知识，内容比较少也很好理解，大家理解记忆即可，这个知识点非常重要，面试被问到的几率是99.9%，所以大家一定要掌握该知识点。

end