rdb传输失败需分三阶段定位：主节点生成失败（查日志、磁盘、内存）、发送失败（查网络、repl-timeout、防火墙）、从节点接收中断（查rdb完整性、权限、磁盘空间），并针对性加固配置预防。

全量同步中 RDB 传输失败，Redis 不会自动重试，需要人工介入或配置保障机制。关键不是“重试动作本身”，而是识别失败原因并针对性处理——因为 RDB 传输卡在不同环节，应对方式完全不同。

先确认失败发生在哪个阶段

RDB 全量同步分三步：主节点生成 RDB → 主节点发送 RDB → 从节点接收并加载。每一步失败表现和日志位置不同：

• 主节点没生成 RDB：查看主节点日志是否有 BGSAVE failed 或磁盘满、内存不足报错；检查 dir 目录权限和空间
• RDB 生成了但没发出去：主节点日志出现 Failed to write to slave 或连接被重置；重点查网络连通性、防火墙、TCP 超时（repl-timeout 默认 60 秒）
• 从节点收了一半就中断：从节点日志提示 Unexpected end of file reading RDB 或 Invalid RDB magic string；说明传输不完整，RDB 文件损坏

手动触发重试的两种可靠方式

不能只靠断开重连——那样可能再次走相同失败路径。推荐以下组合操作：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 清空从节点状态后重试：在从节点执行 REPLICAOF NO ONE 断开，再执行 FLUSHALL 清空残留数据，最后重新 REPLICAOF <master_ip><port></port></master_ip>
• 强制主节点重做 RDB 并跳过缓存积压区：在主节点执行 DEBUG RELOAD（仅开发/测试环境），或更稳妥地先 CONFIG SET repl-backlog-size 10485760 扩大缓冲区，再断开重连

预防比重试更重要

传输失败大多源于配置或资源瓶颈，提前加固可大幅降低发生概率：

• 主从节点都设置足够大的 repl-timeout（建议 ≥ 300），避免网络抖动导致中断
• 主节点 dir 和从节点 dbfilename 路径确保有写权限，且磁盘剩余空间 ≥ 当前 RDB 大小 × 2
• 禁用从节点的 slave-serve-stale-data no 时，要配合 slave-read-only yes，否则加载中拒绝读可能掩盖传输问题
• 生产环境建议开启 repl-diskless-sync yes（无盘复制），绕过本地磁盘 IO，直接 socket 发送 RDB 流

本质上，RDB 传输失败不是“重试几次就能好”的问题，而是系统状态异常的信号。盯住日志、分段验证、配置兜底，比反复执行 REPLICAOF 更有效。