Redis从节点重启必走全量同步，因其master_replid和master_repl_offset丢失，触发PSYNC ? -1指令，主节点只能响应FULLRESYNC；有效缓解方式是RDB预热：提前生成并拷贝最新RDB至从节点，使其启动即带数据，跳过全量同步直连增量。
Redis从节点重启后触发全量同步，不是“慢”，而是会瞬间压垮主节点——尤其当多个从节点一起拉RDB时，fork + 磁盘IO + 网络带宽三重冲击直接让主节点QPS暴跌、延迟飙升。真正有效的缓解方式不是调参数，而是把“同步动作”从启动后移到启动前。
为什么从节点重启必走全量同步？
从节点重启后，它本地的 master_replid 和 master_repl_offset 丢失或不匹配，发 PSYNC ? -1 给主节点，主节点只能响应 +FULLRESYNC。这不是bug，是PSYNC2协议设计的兜底逻辑。
常见误判点：
- 以为开了
repl-diskless-sync yes就能避免风暴——无盘复制只省磁盘IO，不减少fork压力和网络流量 - 以为调大
repl-backlog-size就能保增量——但重启后从节点offset归零，backlog再大也用不上 - 在集群里混用
replica-announce-ip配置，导致从节点起来后连不上主节点，反复重试触发多次PSYNC
用RDB文件预热替代启动后同步
核心思路：不让从节点“空着身子启动”，而是让它带着最新RDB启动，跳过全量同步阶段，直奔增量同步。
操作要点：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 主节点上执行
BGSAVE（或等最近一次自动RDB落盘），确认dump.rdb时间戳最新 - 把该RDB文件拷贝到目标从节点的
dir配置路径下，并确保文件名与dbfilename一致（默认dump.rdb） - 从节点配置中必须关闭
rdb-del-sync-files yes（否则它启动时会删掉你放好的RDB） - 启动前清空该节点的
nodes.conf（避免残留旧集群状态干扰角色识别） - 启动后检查
redis-cli -p 7002 info replication | grep sync_——应快速出现master_sync_in_progress:0，而非长时间卡在1
分批重启从节点并验证状态链
即使做了RDB预热，也不能所有从节点一起启。因为每个节点启动后仍要完成握手、槽位校验、复制流建立，这些操作共享主节点的连接数、CPU和网络缓冲区。
安全节奏建议：
- 每次只启1个从节点，且严格按
cluster nodes输出中角色为slave的节点顺序操作 - 每轮等待满足三个条件才进下一轮：
redis-cli -p 7002 ping可通、redis-cli -p 7002 cluster info显示cluster_state:ok、redis-cli --cluster check 127.0.0.1:7002返回[OK] All 16384 slots covered. - 跳过
redis-cli -p 7002 info replication | grep master_host这类弱验证——它只说明有主节点地址，不保证复制流已稳定 - 若某节点卡在
connecting或noaddr，优先检查其cluster-announce-ip是否指向宿主机可路由IP（K8s环境尤其注意）
预热RDB怎么保证数据新鲜度？
RDB不是越新越好，而是要在“数据一致性”和“时效性”之间找平衡点。生产中最容易被忽略的是时间窗口问题。
关键控制点：
- 不要用
SAVE命令生成RDB——它阻塞主线程，可能卡住正在写的业务请求 - 用
redis-cli -p 6379 BGSAVE后，通过redis-cli -p 6379 info persistence | grep rdb_last_bgsave_time获取完成时间戳，再结合repl-backlog-time-limit推算该RDB是否仍在增量覆盖范围内 - 如果主节点写入QPS高、
repl-backlog-size小（比如默认1MB），RDB生成时刻距现在超过1分钟，就别强求“最新”，宁可接受少量增量追赶，也不要冒险用过期RDB引发数据错乱 - 对金融类场景，建议在RDB生成前后记录
INFO replication中的master_repl_offset，后续比对从节点同步进度是否追平
真正麻烦的从来不是“怎么做”，而是“什么时候做”——RDB预热必须卡在业务低峰、主节点负载低于40%、且网络延迟稳定的时候执行。错过这个窗口，后面所有分批、校验、重试都只是给故障加戏。
