当前位置：首页 > news >正文

MySQL8.0.30 版本中redo log的变化

news 2025/10/30 9:50:37

MySQL redo log记录数据记录变更，以及未数据一致性恢复提供保障。在运维MySQL 过程中，会遇到调整redo log 和redo buffer size 大小的需求，然而修改redo log 文件大小需要重启，不过 MySQL 8.0.30 版本中提供动态调整redo log 文件大小的功能。

https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html

从 MySQL 8.0.30 开始， innodb_redo_log_capacity系统变量控制 redo log 总的大小。

因为在该版本以及之后的版本参数innodb_log_file_size 和 innodb_log_files_in_group 已经被废弃。

如下图所示，8.0.30 版本对原来的循环覆盖写的结构进行了改造，不再以 redo 文件个数和单个 redo 文件的大小来进行限制，而是通过 innodb_redo_log_capacity来指定整个 redo 空间的大小。整个redo空间会被切成32个文件（固定个数），文件按照 ib_redo$SEQ 的方式进行编号，$SEQ 是一个递增的序列号。在文件管理上，所有的文件会被分成两类：

normal redo 文件，命名为 ib_redo$SEQ，正常的 redo 文件，和以前一样，任意时刻只会有一个 redo 文件进行写入；
unused redo 文件，命名为 ib_redo$SEQ_tmp，未被使用的 redo 文件在被使用时，会被重命名为正常文件；

后台的 log_files_governor 线程会负责处理已经写完成的文件，在满足回收条件时，会重新变成 unused redo 文件

当 innodb_redo_log_capacity 发生变化时，已经使用过的和正在使用过的 redo 文件并不会发生改变，仅需要调整 unused redo 文件。当用户修改 innodb_redo_log_capacity 时，会唤醒后台的 log_files_governor 线程，后台线程首先会重新计算当前的 redo_log_capacity，然后根据变化的类型：

如果是空间放大，直接根据放大后的大小，重新生成新的 unused redo 文件；
如果是空间缩小，需要计算当前已使用的空间数能否满足目标值，如果满足，那么缩小过程和放大过程一样，直接重新生成新的 ununsed redo 文件即可；如果不能，还需要在更新 redo_log_capacity 之后，通过调整暴露给 log_writer 和 page_cleaner 线程的 lsn 信息，来加速空间回收；

unused redo 文件的引入，类似于引入了缓存区的机制，因为 unused redo 文件不是正在使用的 redo 文件，所以可以直接进行重建，从而满足 innodb_redo_log_capacity 的设置。

在运行时设置时，配置更改会立即发生，但可能需要一些时间才能完全实现新的限制。如果重做日志文件占用的空间小于指定值，则脏页将从缓冲池中较不积极地刷新到表空间数据文件中，最终增加重做日志文件所占用的磁盘空间。如果重做日志文件占用的空间超过指定值，则会更积极地刷新脏页，最终减少重做日志文件所占用的磁盘空间。