MySQL各种“Buffer”之Log Buffer

GrowthDBA 2021-09-29
666

上回书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是什么

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特性,同时能够提高数据库性能的技术

Redo Log相关参数

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_checksums=ON启用CRC-32C重做日志页面的校验和算法。当innodb_log_checksums被禁用时,重做日志页面校验字段的内容被忽略。重做日志标题页和重做日志检查点页上的校验和永远不会被禁用。默认情况是启用状态,我们按照默认设置就好
  • 参数:innodb_log_file_size
  • 参数:innodb_log_files_in_group
介绍:innodb_log_file_size是日志组每个Redo Log文件的大小,单位字节。日志文件(innodb_log_file_size
innodb_log_files_in_group)
的组合大小不能超过略小于 512GB 的最大值。innodb_log_files_in_group是定义日志组文件的数量。从文章开头的架构图可以看出,Log Buffer也是内存+磁盘的结构,这两个参数就是定义Log Buffer磁盘结构日志文件组的,同时这两个参数也很重要。

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

write pos是当前记录的位置,一边写一边后移,写到第2号文件末尾后就回到0号文件开头。checkpoint是当前要擦除的位置,也是往后推移并且循环的,擦除记录前要把记录更新到数据文件。write pos和checkpoint之间的“Free”部分还空着的部分,可以用来记录新的操作。如果write pos追上checkpoint,表示Redo Log满了,这时候不能再执行新的更新,得停下来把checkpoint推进一下
物理数据目录的Redo Log长下面这个样子:

  • 参数:innodb_flush_log_at_trx_commit

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

Log Buffer工作原理

Redo Log三层架构

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

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

  • 黄色部分:操作系统文件系统的缓冲区(FS Page Cache),这一层,是操作系统OS内核态控制。

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

Redo Log最终落盘的步骤

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,应用程序并不知道,如果操作系统崩溃,数据可能丢失)

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能控制的)

Redo Log刷盘策略最佳实践

高并发业务,行业最佳实践,是使用第三种折衷配置(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


文章转载自 GrowthDBA,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论