主节点磁盘满导致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 才是唯一可信来源。
