运行中切换持久化方案
持久化参数大多不需要重启就能改：CONFIG SET 立即生效，但只作用于运行中的进程。运行时切换持久化方案最典型的操作是 CONFIG SET appendonly yes，Redis 会立刻开始一次基线重写，生成当前数据集的 AOF 基线，此后新的写命令同时追加到 AOF。改动确认无误后必须执行 CONFIG REWRITE 把当前值写回配置文件，否则重启后一切回到旧值，出现「运行行为和配置文件不一致」的状态。
基本信息
| 立即生效 | CONFIG SET 只影响运行中的实例 |
|---|---|
| 落盘 | CONFIG REWRITE 要求配置文件可写 |
| 切换 AOF | 开启 appendonly 会触发一次基线重写 |
| 无法重写的情况 | 通过命令行参数或容器注入配置启动的实例 |
| 核对方式 | INFO persistence 与 CONFIG GET 复核实际值 |
典型使用场景
- 从纯 RDB 平滑切换到 RDB 与 AOF 组合模式
- 临时调整刷盘策略，观察对写入延迟的影响
- 运维窗口内放宽自动重写条件，避免与高峰重叠
- 排查配置文档与运行值长期不一致的历史遗留问题
- 演练结束后把临时参数改回标准值并落盘固化
切换与固化
切换与固化
redis-cli CONFIG SET appendonly yes # 开启 AOF，触发基线重写
redis-cli INFO persistence | grep -E 'aof_enabled|aof_rewrite_in_progress'
redis-cli CONFIG GET appendfsync # 确认刷盘策略
redis-cli CONFIG SET save '900 1 300 10' # 调整快照节奏
redis-cli CONFIG REWRITE # 固化到配置文件
redis-cli CONFIG GET appendonly # 复核实际生效值每一步的作用与风险
| 步骤 | 目的 | 风险 |
|---|---|---|
| CONFIG SET | 立即改变运行行为 | 不落盘，重启即失效 |
| CONFIG REWRITE | 固化到配置文件 | 配置文件不可写时会直接失败 |
| 开启 appendonly | 生成 AOF 基线 | 期间有额外的磁盘与内存开销 |
| 复核 INFO | 确认状态符合预期 | 跳过复核会漏掉改动未生效 |
有些实例是用命令行参数或容器编排注入配置启动的，这类实例执行 CONFIG REWRITE 可能直接报错，或者只写入部分内容。动手前先确认配置来源，把「谁来固化配置」这件事明确下来，否则动态改动就成了不可追溯的临时状态。