Redis CONFIG REWRITE 怎么确认配置真正落盘：路径、权限与重启复核

线上临时用 CONFIG SET 调过 Redis 参数，服务当下恢复了，重启后却又回到旧值，这种故障通常不是 Redis “没记住”，而是运行时配置和磁盘配置本来就是两件事。要确认改动真正落盘，不能只看命令返回 OK：先核对生效值和启动配置文件，再做文件校验，最后在受控重启后重新查询。

CONFIG SET 负责让当前进程立即采用新值，CONFIG REWRITE 才负责把当前生效配置写回 Redis 启动时使用的配置文件；如果 Redis 没有用配置文件启动，重写会直接报错。

正常走完三层核验流程就能确认配置真正落盘：先确认CONFIG REWRITE返回成功后查询进程内生效参数，再核对Redis实际启动加载的配置文件内容已更新、目录与文件权限满足写入要求，最后在预留维护窗口内执行受控重启，重启后重新拉取全量配置校验前后一致。

先分清运行时配置和启动文件

Redis 可以通过 CONFIG SET 在不停机状态下改变一部分参数。这个改变会立即影响当前进程，但不会自动修改 redis.conf。如果此时直接重启，Redis 仍可能按照磁盘上的旧配置启动。

第一步先查询实际生效值。下面的参数仅作演示，生产环境应换成已经审批过的配置项：

redis-cli -h 127.0.0.1 -p 6379 CONFIG GET maxmemory maxmemory-policy
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET dir dbfilename

这里得到的是 Redis 当前进程返回的有效配置，不等于配置文件中的原始文本。尤其是容器、systemd 或托管服务环境，启动文件的路径可能和你登录机器后第一眼看到的文件不同。

CONFIG REWRITE 到底改了什么

CONFIG REWRITE 会根据当前生效配置，尽量保留原配置文件的注释和整体结构，只改写必要的选项。已有选项通常留在原位置；原文件里没有、且当前值不是默认值的选项，才会追加到文件末尾。

redis-cli -h 127.0.0.1 -p 6379 CONFIG REWRITE

成功时返回 OK。Redis 官方实现会以原子方式重写文件，避免进程崩溃时留下半份配置，但这不替代运维侧的备份和验收。命令报错时，常见原因是没有启动配置文件、文件不可写、目录权限不允许创建临时文件，或托管环境禁止这类管理命令。

用文件路径和哈希确认改动落盘

不要凭猜测去改某个名为 redis.conf 的文件。先从服务启动参数、进程管理配置或容器编排文件确认启动入口；如果能访问 Redis，可先用 CONFIG GET 查询与文件位置相关的参数，再结合启动命令核对实际路径。

# 在主机侧确认启动参数与文件位置
ps -ef | grep '[r]edis-server'
systemctl cat redis

# 备份后再查看配置中的关键行
cp /etc/redis/redis.conf /etc/redis/redis.conf.before-rewrite
grep -nE '^(maxmemory|maxmemory-policy|dir|dbfilename)' /etc/redis/redis.conf
shasum -a 256 /etc/redis/redis.conf

文件校验要记录时间、节点、路径和哈希值。若由容器运行，宿主机文件、容器内文件和挂载卷不是同一个检查对象，至少要把容器内实际启动文件与挂载源各核对一次。

默认值、权限和无配置文件启动是三个边界

有些配置被改回默认值后，重写结果里不会出现一条新的显式配置，这不是丢失，而是 Redis 选择用默认值表达当前状态。因此验收要以 CONFIG GET 返回的生效值为主，不能只用文本搜索判断“有没有写进去”。

另一个边界是权限。Redis 进程需要对配置文件及其所在文件夹拥有相应写权限；只给文件写权限而不给目录创建临时文件的能力，也可能导致重写失败。先备份、再检查属主和目录权限，别在生产上直接临时放宽整个目录。

stat -c '%U:%G %a %n' /etc/redis/redis.conf /etc/redis
redis-cli -h 127.0.0.1 -p 6379 CONFIG REWRITE

如果 Redis 是不带配置文件启动的，官方文档明确说明 CONFIG REWRITE 会返回错误。这时不能靠重复执行解决，需要把目标配置纳入正式启动方式，并安排一次受控重启验证。

重启复核才算完成闭环

文件已经变化，仍然只完成了一半。把重启窗口、回滚文件和健康检查准备好后，先记录重启前的生效值，重启完成后用同一组查询再次确认：

redis-cli -h 127.0.0.1 -p 6379 CONFIG GET maxmemory maxmemory-policy
redis-cli -h 127.0.0.1 -p 6379 INFO server
redis-cli -h 127.0.0.1 -p 6379 PING

如果值恢复旧状态，优先检查 Redis 实际加载的文件是否就是刚才重写的那一份，以及 systemd、容器入口或托管平台是否在启动时覆盖了配置。不要马上再次执行 CONFIG SET，那样只会把“启动文件不生效”的问题继续藏在运行时。

集群和副本不要只改一个节点

Redis Cluster 的每个节点都有自己的配置文件和进程状态。只在一个节点执行 CONFIG SET 与 CONFIG REWRITE，不会自动把同一配置复制到其他节点。需要改变的节点要逐一执行，并记录节点地址、文件路径、命令返回和重启复核结果。

副本节点也不能因为不接写流量就跳过。内存上限、文件夹、日志或持久化相关配置不一致，可能在故障切换后才暴露。先按角色列清单，再按节点串行变更，最后抽查主从拓扑和客户端连接。

一份可留档的验收清单

• 已记录变更前后的 CONFIG GET 结果、节点地址和配置项。
• 已确认 Redis 启动使用的真实配置文件，而不是同名的备用文件。
• CONFIG REWRITE 返回 OK，并保留了改动前备份。
• 文件和所在目录权限满足 Redis 进程写回要求，文件哈希已留档。
• 受控重启后，CONFIG GET、PING 和服务健康检查均符合预期。
• 集群或副本节点已逐节点完成，不存在只改主节点的隐性差异。

相关问题

CONFIG SET 返回 OK，为什么重启后还是旧值？

因为它只改变了当前进程的运行时配置。先查询当前值，再执行 CONFIG REWRITE，并确认写回的是 Redis 启动时使用的配置文件。

配置文件里搜不到刚才设置的默认值，是不是重写失败？

不一定。Redis 对默认值通常不额外写入，应该用 CONFIG GET 检查生效状态，同时查看命令返回和文件修改时间。

能不能直接手工编辑 redis.conf？

可以，但必须纳入备份、权限检查和重启复核。对于已经通过 CONFIG SET 调整的参数，先明确运行时值与文件值的差异，再选择手工修改或 CONFIG REWRITE，不要两边同时改而失去变更记录。

总结

Redis 配置持久化的判断标准是一条完整证据链：当前进程的有效值正确，目标启动文件确实被写回，权限和文件校验没有异常，重启后再次查询仍保持预期，所有相关节点也完成了同样的复核。少其中任何一项，都只能说“这次进程看起来对”，还不能说配置已经真正落盘。