MySQL日志（redo log、binlog）刷盘策略.pdf

山

189

5页

13次

2023-11-23

免费下载

MySQL 日志（redo log、binlog）刷盘策略

我们知道 MySQL 是采用两段提交策略来保证事务的原子性的，redo log 刷盘的时机是在事务提交的 commit 阶段采取

刷盘的，在此之前，redo log 都存在于 redo log buffer 这块指定的内存区域中。

1：write 和 fsync 区别#

这里我们首先要明确两个概念和两个参数：

write：刷盘

fsync：持久化到磁盘

write(刷盘)指的是 MySQL 从 buffer pool 中将内容写到系统的 page cache 中，并没有持久化到系统磁盘上。这个速度

其实是很快的。

fsync 指的是从系统的 cache 中将数据持久化到系统磁盘上。这个速度可以认为比较慢，而且也是 IOPS 升高的真正原因。

2：MySQL 日志刷盘控制参数#

innodb_flush_logs_at_trx_commit（redo log）

取值 0：每次提交事务都只把 redo log 留在 redo log buffer 中

取值 1：每次提交事务都将 redo log 持久化到磁盘上，也就是 write+fsync

取值 2：每次都把 redo log 写到系统的 page cache 中，也就是只 write，不 fsync



sync_binlog（binlog）

取值 0：每次提交都将 binlog 从 binlog cache 中 write 到磁盘上，而不 fsync 到磁盘

取值 1：每次提交事务都将 binlog fsync 到磁盘上

取值 N：每次提交事务都将 binlog write 到磁盘上，累计 N 个事务之后，执行 fsync

3：MySQL 没动刷盘场景#

在某些特定场景下，redo log 会在 commit 这个动作到来之前进行刷盘操作，例如下面的两种情况会让没有提交的事

务的 redo log 写入磁盘：

1、redo log buffer 占用的空间即将达到 buffer pool 的一般的时候，后台线程会主动刷盘，这个时候，由于事务没有

提交，所以仅仅是将 redo log buffer 中的内容通过 write 的方法写入到系统的 cache 中，没有进行 fsync 的持久化动

作。

2、并行提交事务的时候，会顺带将上一个事务的部分 redo log 从 redo log buffer 中 fsync 到磁盘上，例如下面的例

子：

假设 redo log buffer 中的内容如下（假设每个事务的 redo log 有 4 部分）：

redo log B1

redo log A1

redo log B2

此时，事务 B 发生了 commit 操作，而设置的 innodb_flush_logs_at_trx_commit 的值是 1，那么会触发事务 B 的 redo

log 持久化到磁盘。此时事务 A 的一部分 redo log，也就是 redo log A1 会被顺带着持久化 fsync 到磁盘中。

这里还需要说明一点，因为 MySQL 的 innodb 存储引擎时需要支持崩溃恢复的，依赖 prepare 阶段的 redo log ，所

以，如果 innodb_flush_logs_at_trx_commit 的值是 1，MySQL 会在 redo log 的 prepare 阶段就进行一次持久化 redo

log 的 fsync 操作。这个 fsync 的存在，再加上每秒一次的后台刷盘操作，innodb 会认为 redo log 在 commit 的时候，

就不需要 fsync 了，只 write 到文件系统的 page cache 就够了。

所以，真正的两阶段提交，应该是下图所示：

of 5

免费下载

mysql

关注

评论