凌晨发布后，Magento 前台突然出现 500，日志里是：

MISCONF Redis is configured to save RDB snapshots,
but it is currently not able to persist on disk

网上最常见的“修复”是一条 CONFIG SET stop-writes-on-bgsave-error no。它确实可能让网站马上恢复写入，但这相当于把烟雾报警器拆掉，并没有处理 RDB 为什么失败。

先判断受影响的是缓存，还是会话

Magento 经常把 default cache、page cache 和 session 放在不同 Redis DB，甚至不同实例。缓存暂时不可写会造成性能下降和页面错误；Session 不可写则可能导致登录、购物车和后台会话丢失。先从 app/etc/env.php 确认实际连接，不要看到 Redis 就执行 FLUSHALL。

记录主机、端口、DB、key 前缀和用途即可，不要在工单里暴露密码。

十分钟内应该收集的证据

redis-cli INFO persistence
redis-cli INFO memory
redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename
df -h
df -i
free -m
journalctl -u redis --since "30 minutes ago"

INFO persistence 里重点看 rdb_last_bgsave_status、rdb_last_bgsave_time_sec 和 rdb_bgsave_in_progress。磁盘空间充足并不代表能写：inode 用尽、目录所有者错误、只读文件系统、容器挂载变化和安全策略都可能让 Redis 无法创建临时 RDB 文件。

磁盘没满时，为什么 BGSAVE 仍会失败

Redis 通过 fork 创建后台保存进程。数据集很大、内存紧张或 overcommit 策略不合适时，fork 本身可能失败。日志通常会出现 Cannot allocate memory。这时清几百 MB 日志不一定有用，需要评估实例内存、峰值写入、容器限制和持久化策略。

另一个常见现场是运维迁移了 dir，新目录存在但 Redis 用户无权写入。用服务实际运行用户验证目录权限，不能用 root 手工创建一个文件就宣布正常。

恢复顺序

  1. 控制应用写入压力，确认是否需要临时切维护模式；
  2. 修复磁盘、inode、权限、只读挂载或内存问题；
  3. 手工触发一次 BGSAVE 或等待计划保存，并确认状态成功；
  4. 验证 Magento Cache、Session、购物车和后台登录；
  5. 观察下一轮自动持久化，而不是看到第一条 PONG 就结束。

什么时候可以临时关闭 stop-writes

只有当 Redis 的业务角色、数据可重建性、主从/备份和数据丢失窗口都经过明确评估，并且团队接受风险时，才可能把它作为短时应急措施。对 Session、队列或其他不可轻易重建的数据，贸然继续写尤其危险。即使临时关闭，也必须有恢复原配置的时间点和负责人。

本次故障关闭前，我会检查一次新的 RDB 文件时间与大小、Redis 日志无新错误、Magento 错误率恢复、Session 不再丢失，并确认磁盘告警阈值已经调整。MISCONF 不是 Magento 缓存故障的同义词，它首先是持久化失败。