MySQL-16.binlog和redo log写入机制以及性能瓶颈在 IO上时.pdf

张鹏

9页

2次

2023-11-07

5墨值下载

2020/3/10 MySQL-16.binlog和redo log写入机制以及性能瓶颈在 IO上时该怎么解决

https://www.jianshu.com/p/7384d6e09048 1/9

MySQL-16.binlog和redo log写入机制以及性能瓶颈在 IO上时

该怎么解决

WAL 机制：只要 redo log 和 binlog 保证持久化到磁盘，就能确保 MySQL 异常重启后，数据可以恢复。

1.binlog 的写入机制

step1.事务执行过程中，先把日志写到 binlog cache

step2.事务提交的时候，再把 binlog cache 写到 binlog 文件中

一个事务的 binlog 是不能被拆开的，因此不论这个事务多大，也要确保一次性写入。这就涉及到了 binlog

cache 的保存问题。系统给 binlog cache 分配了一片内存，每个线程一个，参数 binlog_cache_size 用于控制

单个线程内 binlog cache 所占内存的大小。如果超过了这个参数规定的大小，就要暂存到磁盘。

每个线程有自己 binlog cache，但是共用同一份 binlog 文件。

图中的 write，指的就是指把日志写入到文件系统的 page cache，并没有把数据持久化到磁盘，所以速度比

较快。

图中的 fsync，才是将数据持久化到磁盘的操作。一般情况下，我们认为 fsync 才占磁盘的IOPS。

write 和 fsync 的时机，是由参数 sync_binlog 控制的：

1）sync_binlog=0 的时候，表示每次提交事务都只 write，不 fsync；

2）sync_binlog=1 的时候，表示每次提交事务都会执行 fsync；

3）sync_binlog=N(N>1) 的时候，表示每次提交事务都 write，但累积 N 个事务后才 fsync。

2020/3/10 MySQL-16.binlog和redo log写入机制以及性能瓶颈在 IO上时该怎么解决

https://www.jianshu.com/p/7384d6e09048 2/9

因此，在出现 IO 瓶颈的场景里，将 sync_binlog 设置成一个比较大的值，可以提升性能。在实际的业务场景

中，考虑到丢失日志量的可控性，一般不建议将这个参数设成 0，比较常见的是将其设置为 100~1000 中的某

个数值。

但是，将 sync_binlog 设置为 N，对应的风险是：如果主机发生异常重启，会丢失最近 N 个事务的 binlog 日

志。

2.redo log 的写入机制

事务在执行过程中，生成的redo log 是要先写到 redo log buffer 的。redo log buffer里面的内容，不是每次

生成后都要直接持久化到磁盘。

如果事务执行期间 MySQL 发生异常重启，那这部分日志就丢了。由于事务并没有提交，所以这时日志丢了也

不会有损失。

事务还没提交的时候，redo log buffer 中的部分日志有可能被持久化到磁盘。

redo log 可能存在的三种状态：

1）存在 redo log buffer 中，物理上是在 MySQL 进程内存中，就是图中的红色部分；

2）写到磁盘 (write)，但是没有持久化（fsync)，物理上是在文件系统的 page cache 里面，也就是图中的

黄色部分；

3）持久化到磁盘，对应的是 hard disk，也就是图中的绿色部分。

为了控制 redo log 的写入策略，InnoDB 提供了 innodb_flush_log_at_trx_commit 参数，它有三种可能取

值：

1）设置为 0 的时候，表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ;

2）设置为 1 的时候，表示每次事务提交时都将 redo log 直接持久化到磁盘；

3）设置为 2 的时候，表示每次事务提交时都只是把 redo log 写到 page cache。

of 9

5墨值下载

binlog

关注

评论