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 文件损坏
手动触发重试的两种可靠方式
不能只靠断开重连——那样可能再次走相同失败路径。推荐以下组合操作：
-
清空从节点状态后重试：在从节点执行
REPLICAOF NO ONE断开，再执行FLUSHALL清空残留数据，最后重新REPLICAOF <master_ip> <port> -
强制主节点重做 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 更有效。
