从节点bgsave失败不影响主从同步，因复制依赖主节点replication buffer和repl-backlog-size；主节点bgsave失败（如磁盘满、fork超时）才会导致全量同步卡在wait_bgsave_start或反复断连。
从节点bgsave失败根本不影响主从同步
Redis 从节点执行 bgsave 失败，本身不会导致主从同步中断。主从复制依赖的是主节点的 replication buffer 和 repl-backlog-size，与从节点是否能成功保存 RDB 完全无关。从节点的 bgsave 只服务于它自身的持久化需求，不是复制链路的必要环节。
真正中断同步的，是主节点bgsave失败或卡住
当主节点 bgsave 失败（如磁盘满、fork() 超时、权限不足），会导致首次全量同步卡在 WAIT_BGSAVE_START 状态；若已建立连接但主节点反复 bgsave 失败，则从节点日志会持续出现 MASTER SLAVE sync: receiving bytes from master 后断开——这不是“从节点失败”，而是主节点压根没发出 RDB。
-
INFO persistence中rdb_bgsave_in_progress:1长时间不变为 0，且rdb_last_save_time不更新，就是主节点bgsave卡死的铁证 - 查日志：
grep "Can't save in background" /var/log/redis/redis-server.log，常见报错包括No space left on device、fork() failed - 用
df -h $(redis-cli config get dir | tail -1)确认主节点dir所在文件系统真实使用率，别只看/分区
从节点bgsave失败的典型表现和误判点
从节点自己 bgsave 失败，只会体现为自身 RDB 文件未更新、rdb_last_bgsave_status:err，但 INFO replication 里 master_link_status:up、slave_repl_offset 正常增长。如果你观察到同步中断，却看到从节点日志有 bgsave 报错，大概率是混淆了因果——真正的问题在主节点，或者网络、repl-timeout、client-output-buffer-limit 等配置上。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 从节点
bgsave失败不会触发replicaof重连，也不会影响PSYNC流程 - 如果从节点启用了
save ""（禁用 RDB），它照样可以作为从节点正常接收并应用命令 - 监控时应区分：主节点看
rdb_bgsave_in_progress和latest_fork_usec；从节点只需关注master_link_status和slave_repl_offset增长是否停滞
为什么有人会把“从节点bgsave失败”和同步中断联系起来
因为运维排查时容易被表象误导：比如主从都开了 bgsave，主节点因磁盘满失败，从节点也恰好因同一磁盘问题失败；又或者主节点 bgsave 卡住导致 replication buffer 断流，从节点同时尝试 bgsave 也失败，日志堆在一起就误以为“两个失败有关联”。实际上，它们共享的是底层资源（磁盘、内存、inode），而非逻辑依赖。
真正要盯死的，永远是主节点的 fork() 耗时、repl-backlog-size 是否够大、client-output-buffer-limit slave 是否被冲垮——这些才是同步中断的直接开关。
