前言
本文已收录在MySQL性能优化+原理+实战专栏，点击此处浏览更多优质内容。
上一篇文章MySQL之Doublewrite Buffer详解首次提到Redo Log的概念，Redo Log是数据库体系架构中非常重要的一个模块，它能保证数据库的Crash-safe（崩溃恢复）的能力。而今天要介绍的Log Buffer正和Redo Log息息相关、密不可分。所以我们就来一起来了解它。
官档地址：https://dev.mysql.com/doc/refman/8.0/en/innodb-redo-log-buffer.html
点击此处跳转
目录
- 一、Redo Log是什么
- 二、Redo Log三层架构
- 2.1 Redo Log最终落盘的步骤
- 2.2 MySQL对上述可能存在问题的折衷方案
- 2.3 Redo Log刷盘策略最佳实践
- 三 、Redo Log相关参数
- 2.1 innodb_log_buffer_size
- 2.2 innodb_log_checksums
- 2.3 innodb_log_compressed_pages
- 2.4 innodb_log_file_size & innodb_log_files_in_group
- 2.5 innodb_flush_log_at_trx_commit
一、Redo Log是什么
Redo Log（重做日志）是MySQL中非常重要的日志模块
MySQL官方给出的解释是：日志缓冲区是存储要写入磁盘上的日志文件的数据的内存区域，日志缓冲区的内容定期刷新到磁盘。
重做日志是一种基于磁盘的数据结构，用于在崩溃恢复期间纠正不完整事务写入的数据。在正常操作期间，重做日志对由SQL语句或低级API调用产生的更改表数据的请求进行编码。在初始化期间和接受连接之前，会自动重播在意外关闭之前未完成更新数据文件的修改，MySQL里经常说到的WAL技术（WAL的全称是Write-Ahead Logging），它的关键点就是日志先行（也称为写前日志，实际写数据之前，先把修改的数据记录到日志文之间中。即先写日志，再写磁盘），其实很多数据库软件设计的理念都是日志先行。MySQL中日志先行的这个“日志”就是Redo Log。
Redo Log是InnoDB引擎特有的日志，正是因为有了Redo Log，才保证了InnoDB存储引擎的Crash-safe能力。
Redo Log是物理日志，记录的是“在某个数据页上做了什么修改（做了什么改动）”。一句话概括一下：Redo Log是为了保证已提交事务的ACID特性，同时能够提高数据库性能的技术。
二、Redo Log三层架构
简单来说一下Redo Log的三层结构：
- 粉色部分：是InnoDB一项很重要的内存结构（In-Memory Structure），即我们的Log Buffer（日志缓冲区），这一层，是MySQL应用程序用户态控制。
- 黄色部分：操作系统文件系统的缓冲区（FS Page Cache），这一层，是操作系统OS内核态控制。
- 绿色部分：就是落盘的物理日志文件。
2.1 Redo Log最终落盘的步骤
- 首先，事务提交的时候，会写入Log Buffer，这里调用的是MySQL自己的函数
WriteRedoLog； - 接着，只有当MySQL发起系统调用写文件write时，Log Buffer里的数据，才会写到FS Page Cache。注意，MySQL系统调用完write之后，就认为文件已经写完，如果不flush，什么时候落盘，是操作系统决定的；
- 最后，由操作系统（当然，MySQL也可以主动flush）将FS Page Cache里的数据，最终fsync到磁盘上；
操作系统为什么要缓冲数据到FS Page Cache里，而不直接刷盘呢？
这里就是将“每次写”优化为“批量写”，以提高操作系统性能。
数据库为什么要缓冲数据到Log Buffer里，而不是直接write呢？
这也是“每次写”优化为“批量写”思路的体现，以提高数据库性能。
Redo Log三层架构，MySQL做了一次批量写优化，OS做了一次批量写优化，确实能极大提升性能，但有什么副作用吗？
有优点，必有缺点。这个副作用，就是可能丢失数据：
事务提交时，将Redo Log写入Log Buffer，就会认为事务提交成功
如果写入Log Buffer的数据，write入FS Page Cache之前，数据库崩溃，就会出现数据丢失
如果写入FS Page Cache的数据，fsync入磁盘之前，操作系统奔溃，也可能出现数据丢失；
如上文所说，应用程序系统调用完write之后（不可能每次write后都立刻flush，这样写日志很蠢），就认为写成功了，操作系统何时fsync，应用程序并不知道，如果操作系统崩溃，数据可能丢失）
2.2 MySQL对上述可能存在问题的折衷方案
参数innodb_flush_log_at_trx_commit能够控制事务提交时，刷Redo Log的策略，目前有三种策略，即对应可设置的值可以是0、1或2。
-
策略一：最佳性能（innodb_flush_log_at_trx_commit=0）
处理过程： 每隔一秒，才将Log Buffer中的数据批量write入FS Page Cache，同时MySQL主动fsync。
缺点： 这种策略，如果数据库奔溃，有一秒的数据丢失。 -
策略二：强一致（innodb_flush_log_at_trx_commit=1）
处理过程： 每次事务提交，都将Log Buffer中的数据write入FS Page Cache，同时MySQL主动fsync。这种策略，是InnoDB的默认配置，为的是保证事务ACID特性。
缺点： 这种策略，性能较其余两种策略较差。 -
策略三：折衷（innodb_flush_log_at_trx_commit=2）
处理过程： 每次事务提交，都将Log Buffer中的数据write入FS Page Cache；每隔一秒，MySQL主动将FS Page Cache中的数据批量fsync。
缺点： 这种策略，如果操作系统奔溃，最多有一秒的数据丢失。（因为OS也会fsync，MySQL主动fsync的周期是一秒，所以最多丢一秒数据。磁盘IO次数不确定，因为操作系统的fsync频率并不是MySQL能控制的）
2.3 Redo Log刷盘策略最佳实践
高并发业务，行业最佳实践，是使用第三种折衷配置（innodb_flush_log_at_trx_commit=2），这是因为：
-
配置为2和配置为0，性能差异并不大，因为将数据从Log Buffer拷贝到FS Page Cache，虽然跨越用户态与内核态，但毕竟只是内存的数据拷贝，速度很快；
-
配置为2和配置为0，安全性差异巨大，操作系统崩溃的概率相比MySQL应用程序崩溃的概率，小很多，设置为2，只要操作系统不奔溃，也绝对不会丢数据。
三 、Redo Log相关参数
mysql> show variables like '%innodb_log%';
+------------------------------------+----------+
| Variable_name | Value |
+------------------------------------+----------+
| innodb_log_buffer_size | 16777216 |
| innodb_log_checksums | ON |
| innodb_log_compressed_pages | ON |
| innodb_log_file_size | 50331648 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_log_spin_cpu_abs_lwm | 80 |
| innodb_log_spin_cpu_pct_hwm | 50 |
| innodb_log_wait_for_flush_spin_hwm | 400 |
| innodb_log_write_ahead_size | 8192 |
| innodb_log_writer_threads | ON |
+------------------------------------+----------+
11 rows in set (0.01 sec)
mysql> show variables like '%innodb_flush_log%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_timeout | 1 |
| innodb_flush_log_at_trx_commit | 1 |
+--------------------------------+-------+
2 rows in set (0.00 sec)
从上面可以看出，Redo Log的相关参数还是很多的，所以我们拿重点的来说，其余参数一般为默认值，感兴趣的可移步MySQL官档（https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html）进行查阅
2.1 innodb_log_buffer_size
InnoDB用于写入磁盘上的日志文件的缓冲区的大小（以字节为单位）。这就是定义我们文章标题的Log Buffer大小的参数。随着32KB和64KBinnodb_page_size值的引入，默认值从8MB更改为16MB。大型日志缓冲区使大型事务能够运行，而无需在事务提交之前将日志写入磁盘。因此，如果您有更新、插入或删除许多行的事务，则增大日志缓冲区可以节省磁盘 I/O。
set persist innodb_log_buffer_size =33554432;
2.2 innodb_log_checksums
启用或禁用重做日志页面的校验和，当innodb_log_checksums被禁用时，重做日志页面校验字段的内容被忽略，默认是开启
set persist innodb_log_checksums = on;
2.3 innodb_log_compressed_pages
日志文件页存储压缩 , 将减少redo log的写入量。默认是开启
set persist innodb_log_compressed_pages= on;
2.4 innodb_log_file_size & innodb_log_files_in_group
innodb_log_file_size是日志组每个Redo Log文件的大小，单位字节
innodb_log_files_in_group是定义日志组文件的数量
innodb_log_file_size * innodb_log_files_in_group 组合大小不能超过略小于 512GB 的最大值。从文章开头的架构图可以看出，Log Buffer也是内存+磁盘的结构，这两个参数就是定义Log Buffer磁盘结构日志文件组的，同时这两个参数也很重要。
write pos是当前记录的位置，一边写一边后移，写到第2号文件末尾后就回到0号文件开头。checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。write pos和checkpoint之间的“Free”部分还空着的部分，可以用来记录新的操作。如果write pos追上checkpoint，表示Redo Log满了，这时候不能再执行新的更新，得停下来把checkpoint推进一下
2.5 innodb_flush_log_at_trx_commit
控制提交操作的严格ACID合规性与当与提交相关的I/O操作重新排列并批量完成时可能实现的更高性能之间的平衡。这个参数非常重要，后面的Log Buffer原理主要是关于这个参数的。设置的值不同会产生不同的效果，可设置的值可以是0、1或2。
- 1：表示每次事务提交都会将redo log buffer刷写到redo log
- 0：表示每次事务提交不会刷写到redo log，而是一秒后再刷写到redo log
- 2：表示每次事务提交不会刷写到redo log，而是存放到os cache，等一秒后再刷写到redo log
今天主要讲解了Redo Log和MySQL InnoDB Log Buffer的工作原理，通过流程图的方式来说明Redo Log三种刷盘策略的工作流程，偏理论的知识，内容比较少也很好理解，大家理解记忆即可
