一文带你了解MySQL之Log Buffer_mysql log 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（重做日志）是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)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

从上面可以看出，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;
1

2.2 innodb_log_checksums

启用或禁用重做日志页面的校验和，当innodb_log_checksums被禁用时，重做日志页面校验字段的内容被忽略，默认是开启

set persist innodb_log_checksums = on;
1

2.3 innodb_log_compressed_pages

日志文件页存储压缩 , 将减少redo log的写入量。默认是开启

set persist innodb_log_compressed_pages= on;
1

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三种刷盘策略的工作流程，偏理论的知识，内容比较少也很好理解，大家理解记忆即可

至此今天的学习就到此结束了，愿您成为坚不可摧的自己~~~
​

You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.You have to trust in something - your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life

如果我的内容对你有帮助，请 点赞、评论、收藏，创作不易，大家的支持就是我坚持下去的动力