是的，磁盘空间不足是Redis主从同步失败的常见根因，主节点磁盘满导致bgsave失败，从节点卡在wait_bgsave状态；需查config get dir确认真实路径、df -h查该路径使用率≥95%、日志中“No space left on device”报错及info persistence中rdb_bgsave_in_progress长期为1且rdb_last_save_time停滞。
是的，磁盘空间不足是 Redis 主从同步失败的常见且隐蔽的根因之一，尤其在全量同步阶段——它不报“同步失败”，而是让从节点卡在 wait_bgsave 状态，日志里反复出现连接中断、MASTER <-> SLAVE sync: receiving bytes from master 后断开，INFO replication 中 slave_repl_offset 停滞不动。
查主节点 dir 路径的真实磁盘使用率
很多人只跑 df -h / 或 df -h /var，但 Redis 的 RDB 文件写入位置由配置项 dir 决定，它可能指向独立挂载点（比如 /data/redis 或 /mnt/redis-data）。这个路径才是 bgsave 实际落盘的地方。
- 先确认真实路径：
redis-cli config get dir - 再查对应分区：
df -h /data/redis（把路径替换成你查到的值） - 重点关注
Use%是否 ≥95%，哪怕/还有 40% 空间，/data/redis满了照样同步失败
看日志里有没有 No space left on device
这不是模糊提示，而是操作系统返回的明确错误。只要 bgsave 进程试图创建或写入 .rdb 文件时磁盘满，就会在 Redis 日志中留下痕迹。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 查关键错误：
grep "No space left on device" /var/log/redis/redis-server.log - 或定位 bgsave 失败记录：
grep "bgsave" /var/log/redis/redis-server.log | tail -20 - 典型报错：
Failed to open dump.rdb for saving: No space left on device或Can't save in background: fork: Cannot allocate memory（后者常伴随磁盘满引发的内存分配失败）
INFO persistence 里 rdb_bgsave_in_progress 长期为 1
这个指标是判断 bgsave 是否真正卡住的最直接证据。正常流程是：触发 → rdb_bgsave_in_progress:1 → 完成 → 变为 0 并更新 rdb_last_save_time。如果它卡在 1 不动，且 rdb_last_save_time 几分钟没变化，基本就是落盘失败了。
- 执行：
redis-cli info persistence | grep -E "(rdb_bgsave_in_progress|rdb_last_save_time)" - 注意：不要只看
rdb_bgsave_in_progress:1，要结合rdb_last_save_time是否停滞 - 如果
rdb_bgsave_in_progress:0却仍同步失败，问题大概率不在磁盘，需转向网络、缓冲区或积压区排查
为什么磁盘满会导致从节点“假死”而非报错
因为 Redis 主从同步的全量阶段依赖 bgsave 成功生成 RDB 文件。主节点磁盘满 → bgsave 失败 → RDB 文件根本没产生 → 从节点永远收不到文件 → 一直卡在 wait_bgsave 状态，既不超时也不报错，只默默重试。
- 从节点日志不会说“主节点磁盘满了”，只会循环打印接收字节数后断开
-
INFO replication中master_last_io_seconds_ago持续增大，说明主节点根本没发数据过去 - 最容易被忽略的是：这个问题和网络、timeout、repl-backlog 都无关，查错方向必须第一时间落到主节点磁盘
