错误本质是redis因rdb持久化失败主动停写，设为no仅应急，不解决磁盘满、权限不足等根因，且重启失效；必须同步排查df -h、ls -ld和日志定位真实问题。

这个错误不是 Redis 本身坏了，而是它主动“刹车”了——因为 RDB 快照写磁盘失败，stop-writes-on-bgsave-error 配置项为 yes，所以直接禁掉所有写命令（SET、DEL、FLUSHALL 等全挂了）。

为什么 CONFIG SET stop-writes-on-bgsave-error no 只能应急？

这条命令确实能让写操作立刻恢复，但它不解决根本问题：RDB 还是存不进磁盘。后续只要 bgsave 再失败一次，Redis 就可能再次触发保护。更危险的是，如果磁盘已满或权限丢失，你只是把报错藏起来了，数据其实没落盘，重启就丢。

• CONFIG SET 修改是运行时生效，Redis 重启后失效（除非也改了 redis.conf）
• 生产环境禁用该保护前，必须确认：磁盘有空间、目录可写、内存够用、overcommit_memory 已设为 1
• 执行后务必验证：redis-cli INFO persistence | grep rdb_bgsave_in_progress 看是否真能开始快照

查磁盘和权限：df -h 和 ls -ld /var/lib/redis 必做

90% 的真实案例卡在这两步。别跳过，别靠猜。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 运行 df -h，重点看 Use% 列——如果某个分区到 95%+，dump.rdb 写一半就失败，Redis 就会停写
• 运行 ls -ld $(redis-cli CONFIG GET dir | awk '{print $2}')，确认输出里包含 redis:redis 和至少 drwxr-xr-x 权限；否则 bgsave 进程（以 redis 用户身份运行）根本打不开目标目录
• 常见陷阱：/var/lib/redis 目录存在，但父目录（比如 /var/lib）权限是 drwx------，redis 用户照样进不去

看日志才能定位真实失败原因

INFO persistence 只告诉你“快照失败”，但不告诉你为啥失败。真正线索在 Redis 日志里。

• 先查日志路径：redis-cli CONFIG GET logfile；如果返回空，说明日志输出到 stdout（常见于容器部署），得用 docker logs redis 或 journalctl -u redis-server
• 日志里搜 Can't save in background、Failed opening .rdb for saving、Permission denied —— 这些才是根因提示
• 如果日志里反复出现 Background save terminated by signal 9，大概率是 OOM Killer 杀了 bgsave 子进程，这时要调 vm.overcommit_memory = 1 并检查内存压力

临时切 AOF 或关持久化：慎用但有时真管用

当 RDB 死活搞不定，又急需恢复服务时，可以换条路走，但得清楚代价。

• 切 AOF：CONFIG SET appendonly yes + CONFIG SET appendfsync everysec，AOF 对磁盘压力小、容错强，但首次重写可能卡住；注意 AOF 文件增长快，得配 auto-aof-rewrite-percentage
• 彻底关持久化：CONFIG SET save ""，RDB 规则清空，bgsave 不再自动触发——这等于放弃落地保障，只适合纯缓存场景或极短期兜底
• 任何运行时配置变更后，记得同步更新 redis.conf，否则重启即回归故障状态

最常被忽略的一点：这个错误从来不是孤立发生的。它永远是磁盘、权限、内存、内核参数中某一个环节先出问题，Redis 只是那个大声报警的哨兵。盯着 stop-writes-on-bgsave-error 改来改去，不如花三分钟看一眼 df -h 和日志最后一行。