MySQL 动态 redo 日志容量怎么设置

MySQL 8.x 可以直接修改 innodb_redo_log_capacity，不必为了调整 redo 总容量重启实例。正确做法不是照抄一个“8GB 通用值”，而是先测高峰期 redo 生成速率，再选择希望覆盖的缓冲时间，得到候选容量后在线调整并观察实际收敛状态。

官方说明：https://dev.mysql.com/doc/refman/8.4/en/innodb-redo-log.html

先用“高峰 redo 字节/秒 × 目标缓冲秒数”得到基线，再预留容量余量。上线时只改一档，并同时观察 checkpoint 距离、resize 状态、磁盘空间和刷脏压力。

先分清三个容量概念

innodb_redo_log_capacity 是配置目标；Innodb_redo_log_capacity_resized 是当前已经实施的总容量；Innodb_redo_log_logical_size 与 Innodb_redo_log_physical_size 则反映逻辑占用和物理占用。修改变量后，配置会立即接受，但文件调整可能需要一段时间，所以不能只看 SHOW VARIABLES 就认定完成。

按写入压力估算候选容量

容量估算可以从高峰写入窗口入手。每隔固定时间读取 Innodb_redo_log_current_lsn，用两次差值除以秒数，得到这段时间的 redo 生成速率。不要只取平均值，应覆盖业务高峰、批量导入或大事务时段。

-- 第一次记录当前 LSN，稍后用同一语句再次取值
SHOW GLOBAL STATUS LIKE 'Innodb_redo_log_current_lsn';

-- 同时记录检查点位置，用差值观察活跃 redo 压力
SHOW GLOBAL STATUS LIKE 'Innodb_redo_log_checkpoint_lsn';

例如高峰期约产生 40MB/s redo，希望容量覆盖 10 分钟，那么基线约为 24GB；再结合磁盘余量和恢复目标增加适当余量。这里的“覆盖时间”是团队自己的运维目标，不是 MySQL 固定推荐值。写入波动越大，越应该用多个高峰样本，而不是一次测量直接定案。

在线修改并确认容量收敛

先记录当前值和磁盘余量，再用字节数设置目标。下面示例把容量调整为 8GiB。MySQL 8.4 文档给出的变量范围是 8MiB 到 512GiB，默认值为 100MiB；生产环境仍应以实例实际版本的变量元数据为准。

-- 查看当前目标容量
SHOW VARIABLES LIKE 'innodb_redo_log_capacity';

-- 在线设置为 8GiB，SET GLOBAL 本身不会替你检查磁盘规划
SET GLOBAL innodb_redo_log_capacity = 8589934592;

-- 查看调整状态与当前已实施容量
SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Innodb_redo_log_resize_status',
  'Innodb_redo_log_capacity_resized',
  'Innodb_redo_log_logical_size',
  'Innodb_redo_log_physical_size'
);

扩容时，如果现有 redo 文件占用低于目标，InnoDB 会降低刷脏积极程度，物理占用随后逐步增加；缩容时则会更积极地刷脏，让占用逐步下降。官方文档还说明 InnoDB 会尽量维护 32 个 redo 文件，每个文件目标大小约为总容量的 1/32，但刚改完时文件大小可能暂时不一致。

什么时候继续调，什么时候先停

如果高峰期 checkpoint 距离持续逼近容量、刷脏压力明显上升且磁盘仍有余量，可以考虑再增加一档；如果逻辑占用长期很低，就没有必要把容量推到上限。缩容前要确认当前逻辑占用能够安全落入新目标，否则系统会用更积极的刷脏来完成收缩，可能给存储带来额外压力。

• 容量偏小：高峰期检查点推进压力大，后台刷脏更积极。
• 容量偏大：占用更多磁盘，崩溃恢复可能需要处理更大的 redo 范围。
• 只改运行值：实例重启后的配置来源仍要单独管理，避免回到旧值。
• 专用服务器：启用 innodb_dedicated_server 且未显式设置容量时，InnoDB 可以自动计算该参数。

改完变量后为什么文件没有立刻变小？

因为配置接受和物理收敛是两件事。缩容需要推进 checkpoint、刷出脏页并逐步回收 redo 文件，先看 Innodb_redo_log_resize_status，再看已实施容量和物理占用。

还要同时设置 innodb_log_file_size 吗？

不需要。定义 innodb_redo_log_capacity 后，它会取代旧的 innodb_log_file_size 与 innodb_log_files_in_group 容量组合，避免新旧参数同时表达同一目标。

动态 redo 容量的核心不是“能在线改”，而是“能用数据决定改多少”。把高峰 redo 速率、目标缓冲时间和磁盘边界放在一起，再用 resize、LSN 与占用状态观察结果，才能让扩容真正缓解写入压力，也避免一次调得过大。