主节点磁盘满导致bgsave失败，进而使从节点全量同步卡在wait_bgsave状态；需通过df -h查redis实际dir路径磁盘使用率、日志中“no space left on device”报错及info persistence中rdb_bgsave_in_progress异常确认。

主节点磁盘满 → bgsave 失败 → 从节点全量同步卡死

这是个典型的“连锁雪崩”：主节点磁盘写满，bgsave 进程无法生成 RDB 文件，导致全量同步永远卡在 wait_bgsave 状态。从节点日志里反复出现 MASTER SLAVE sync: receiving ... bytes from master 然后断开，但你查 INFO replication 会发现 master_last_io_seconds_ago 持续增大、slave_repl_offset 停滞不动——问题不在网络或缓存区，而在主节点根本没发出 RDB。

怎么确认是磁盘满引发的 bgsave 失败

别猜，直接查三处：

• 登录主节点服务器，运行 df -h /var/lib/redis（或你的 dir 配置路径），看是否 Use% ≥95%
• 查 Redis 日志：grep "Can't save in background" /var/log/redis/redis-server.log 或类似报错；更直接的是 grep "bgsave" /var/log/redis/redis-server.log | tail -20，常见错误如 Failed to open .rdb for saving: No space left on device
• Redis 内部状态：redis-cli info persistence | grep rdb_bgsave_in_progress 如果返回 rdb_bgsave_in_progress:1 却长时间不变成 0，且 rdb_last_save_time 不更新，基本坐实落盘失败

config get dir 和系统磁盘不是一回事，务必核对真实路径

很多人只查 / 或 /var 分区剩余空间，却忽略 Redis 的 dir 配置可能指向独立挂载点（比如 /data/redis）。这个路径才是 bgsave 写 RDB 的地方。

• 执行 redis-cli config get dir 获取实际路径
• 再用 df -h $(redis-cli config get dir | tail -1) 查该路径所在文件系统的使用率
• 注意：Docker 容器中要进容器查，宿主机 df 看不到容器内挂载点的真实用量
• 云数据库（如阿里云 Redis）需看控制台“磁盘使用率”监控，而非 SSH 登录查 —— 它们通常不暴露真实文件系统

临时救急与长期预防怎么做

磁盘满是系统级问题，Redis 自身无权清理磁盘，只能靠外部干预 + 监控兜底：

• 紧急释放：删掉旧 RDB/AOF（确认从库已追平）、清空 dir 下非关键临时文件；切勿删正在使用的 dump.rdb 或 appendonly.aof
• 立即停写：若业务允许，临时将写流量切走，避免 bgsave 反复失败加重阻塞
• 加监控：必须对 dir 所在磁盘做 disk_usage_percent > 85% 告警，不能只盯 Redis 内存
• 配置加固：在 redis.conf 中显式设置 stop-writes-on-bgsave-error yes（默认开启），让写失败早暴露，而不是静默卡住同步

最常被忽略的一点：监控脚本里硬编码了 /var/lib/redis，但生产环境 dir 是通过启动参数 --dir 覆盖的，config get dir 才是唯一可信来源。