重做日志改大小要停机：这批 InnoDB 参数得在建库那天定死
一、参数分三类，验收要查的是第三类
有一篇讲生产环境 MySQL 8.0 日志空间规划的技术文，读完留下的判断不是”哪几个值该调大”，而是一件更基础的分类工作：InnoDB 的参数按变更代价至少分三种性质。第一种是运营期可调项，改下去当场能观察到效果，回滚也只是再改回来；第二种要重启才生效，风险集中在变更窗口本身；第三种是建仓期决定，值不难写，难在它和磁盘上已经形成的结构绑死了，动它意味着干净关闭、搬文件或者重建表空间。
麻烦集中在第三种，而多数团队的检查表里只有前两种的位置。上线前的评审通常问”这套配置跑得快不快”，很少问”这项三年后要改，谁付那次停机”。洹拓在新建实例的方案评审里把第三类单列一栏，要求每一项都写清决定时点、改动代价和签字人，因为这类参数一旦进入运营期，改它就是一次小型迁移项目，不是一个配置动作。
重做日志的大小就属于第三种。总大小由 innodb_log_file_size 与 innodb_log_files_in_group 相乘得到，这两个键看起来只是两行配置，实际决定的是日志文件的物理形态：改动它要先把 innodb_fast_shutdown 置 0 做干净关闭，等脏页与日志推进到一致状态，删除旧的日志文件，改完配置再启动。这条工序里没有任何一步是可以边跑业务边做的。它和检查点推进、崩溃后需要重放的量互相耦合，所以取值方法不该是抄一个通用标准，而是从写入速率与可接受的恢复时间两头推出来，推的过程要留档，否则接手的人无法判断这个值是算出来的还是抄来的。
二、刷盘档位、恢复目标与磁盘能力是一个三角
innodb_flush_log_at_trx_commit 决定事务提交时日志是否落盘。取 1 对应零丢失的恢复目标；这个档位的前提是底层盘真的有低延迟的刷盘能力，固态盘力不足时，提交路径上的等待会直接变成业务侧的响应时间。取 2 换来更少的同步刷盘，代价是宕机时最多丢掉一秒内提交的事务。
这三件事构成三角：恢复目标、刷盘档位、磁盘能力。只调档位而不看盘，代价会搬到宕机恢复和响应抖动上；只按恢复目标定档位而不看真实写入形态，容量侧会以另一种形式找回来。所以取值顺序是固定的三步：先让业务方回答”宕机后能不能接受丢掉一秒内提交的订单状态”，这一步决定档位；再确认实例在自身写入形态下的刷盘延迟表现，注意是自身形态而不是标称值，这一步验证档位能不能守住；最后才把数字写进配置。
验收时我们把”档位”和”恢复目标”钉在同一页上。写下取 1 但拿不出盘侧证据的，按缺陷处理，不当作配置偏好；业务口径要求零丢失却选了宽松档位的，要么改档位要么改恢复目标，不允许两边各留一句免责。这个三角里最容易被忽略的是第三个变量：前两项都在配置文件和合同里，第三项在基础设施上，跨部门时才被发现没人负责过。
三、回滚日志的三件事：位置、截断与清理
回滚日志侧同样有一处属于建仓期决定。innodb_undo_directory 默认与数据同目录，带来的后果在读路径和容量两条上：一是回滚日志的读写与数据文件争同一块盘的吞吐，二是这部分空间的增长混在数据目录里，容量规划变得不可控。把它放到独立位置属于目录规划阶段的事，后面再挪就是文件级的搬迁动作，风险和停机同级。
第二件事是 innodb_undo_log_truncate。这个截断开关不打开，回滚日志在长事务期间只增不减；开了，才有回收的可能，但回收时机受 innodb_max_undo_log_size 与清理线程数 innodb_purge_threads 影响。这里有一个常见的误判：以为打开截断就等于空间受控。实际是”膨胀由长事务决定，回收由开关、阈值与清理能力决定”，两条各自成立才能收敛。只把希望放在截断开关上、不去约束长事务，等于把容量风险换成一段不可预期的回收窗口。
因此这组参数的正确读法是配对关系而不是独立条目。截断开关与阈值配对，阈值与清理线程配对，整组又与业务侧的长事务监控配对。我们在交付时要求的不是某个具体数值，而是这三对关系都能在配置里读出来，并且长事务的处置责任人写进运维手册，避免清理能力被单个批处理任务长期压住。至于是不是要调大线程数，判断依据是回收速度是否跟得上业务膨胀速度，这需要观察数据，不能凭空定。
四、归档类能力只在备份窗口内存在
重做日志的归档能力用于物理备份窗口，它有一个前置条件：需要较高的小版本才具备。这类能力的危险不在功能本身，而在它的使用纪律。归档目录必须落在独立挂载点上，归档期间会持续产出分片文件，而停止归档之后这些分片不会被自动清理。
三条纪律对应三种失效。挂载点不独立，分片增长挤占数据或日志空间，最后先出事的是磁盘而不是备份任务；开启后没人负责停止，归档会一直产出；停止后没人负责清理，历史分片安静地留在盘上，等到下一次备份窗口才发现空间不够。这类问题最典型的处理现场是：备份窗口失败，运维在磁盘告警里翻出一堆不知道谁建的归档分片。
所以我们的做法是把归档当成一个有生命周期的临时状态来管，而不是一个”开了就更安全”的开关。开启要有工单，写明窗口起止、责任人和停止动作；窗口结束要有停止确认与分片清点记录；清理要有责任人，且不允许由”以后有空再删”代替。跨备份方案交接时，这份责任归属要随文档一起移交，因为归档目录里的东西往往比配置更能说明历史。
五、核心交付物：一次性决定清单
把上面四节归拢成一张表，就是我们要求的初始化评审签字件。表的价值不在列出的值，而在”决定时点”和”改动代价”两栏被写清——它们决定了这项参数在运营期是可调项还是一次迁移项目。
| 参数或能力 | 建库期要定的内容 | 之后再改的代价 | 签字角色 |
|---|---|---|---|
innodb_log_file_size 乘 innodb_log_files_in_group |
按写入速率与可接受恢复时间反推总大小，推导过程留档 | 需 innodb_fast_shutdown 置 0 干净关闭、删旧日志、改配置重启；恢复时间要重估 |
数据库负责人与运维值班经理 |
innodb_flush_log_at_trx_commit |
与业务恢复目标同页确定，附盘侧刷盘延迟证据 | 当场可改，但档位与恢复目标不匹配时，代价转成宕机丢数或响应抖动 | 业务方（恢复目标归属方） |
innodb_undo_directory |
是否与数据目录分离，空间增长如何独立计量 | 属文件级搬迁，按停机事件处理 | 架构与存储负责人 |
innodb_undo_log_truncate、innodb_max_undo_log_size、innodb_purge_threads |
三对配对关系写清，附长事务处置责任人 | 开关可改，但已膨胀部分何时回收不可预期 | 数据库负责人与应用负责人 |
| 重做日志归档 | 备份窗口起止、独立挂载点、停止与清理责任人 | 长期开启或无人清理会耗尽磁盘空间，需高小版本 | 备份任务责任人 |
这张表要随实例交付，而不是一次性写完就归档。判据很简单：新增一个实例或接入一个存量实例时，五行都能填出内容才算过；任何一格空着，就必须在验收记录里写成空白项并指定补偿措施，而不是默认”厂商配置应该没问题”。
六、把改动成本量化到工序里
第三类参数的真实成本不是那次重启，而是围绕它的一整套工序。我们在变更方案里要求三件东西同时存在：停机窗口的长度与申请路径，包括业务侧谁能批准；回退方案，具体到配置文件的哪一行改回去、旧日志或旧目录如何处理，而不是”改回原值”；验证项，至少覆盖干净关闭耗时、启动后检查点推进是否正常、恢复演练能否在预期时间内完成。三件里少写一件，方案就不算完整。
演练要放在副本上做一次。改重做日志大小这类动作，只在测试环境里”配过一遍”是不够的，因为它的不确定性集中在关闭与启动阶段的时长；在一份可用副本上完整跑一次，把关闭、删除、改配置、启动的实测时长记下来，才有资格在正式变更里承诺窗口长度。这份记录同时是给业务方看沟通材料，避免窗口谈判凭印象。
还有一层意义在交付阶段划分上。建仓期锁定的决定应当出现在项目第一阶段的工作项里，与建库、账号体系、备份方案并列，而不是塞进”上线后优化”那一栏。列在优化栏的后果是可预期的：它永远不会被做，直到某次容量告警把它变成一个没有计划窗口的应急变更。至于清单本身，它管的是责任与时点，不是答案；照抄一组参数并不等于安全，安全来自每一项都知道为什么是这个值、以及要改时该走哪道工序。