从节点重启后有时需全量同步，是因为断连期间主节点复制积压缓冲区（repl-backlog）已被覆盖，导致无法满足增量同步条件；此时PSYNC请求失败，被迫回退至耗资源的全量同步。

从节点重启后会自动重连并同步，但能否“秒恢复”取决于复制积压缓冲区是否还存着断连期间的数据。

从节点重启后为什么有时要全量同步？

Redis 从节点断连后，主节点靠 repl-backlog（复制积压缓冲区）暂存最近写命令。这个缓冲区是固定大小的环形队列，默认仅 1MB（repl-backlog-size），且只保留最近的写入偏移量（repl-backlog-off）。一旦从节点断开时间过长，或主节点写入量太大，旧命令就被新命令覆盖——此时从节点重连时无法用 PSYNC 请求增量数据，只能触发全量同步。

• 全量同步会阻塞主节点 fork 子进程、生成 RDB、传输大文件，对网络和 CPU 压力明显
• 常见现象：INFO replication 中看到 master_repl_offset 和 slave_repl_offset 差值持续增大，重启后日志出现 Partial resynchronization not possible
• 判断依据：对比 repl-backlog-active（是否启用）、repl-backlog-size 和实际写入速率（如每秒写入 KB 数 × 断连秒数）

如何避免频繁全量同步？

关键不是“让从节点快点重启”，而是让主节点的缓冲区撑得住断连窗口。这不是调高一个参数就能解决的事，得结合实际流量估算：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 先用 redis-cli -h <master-ip> -p <port> INFO replication</port></master-ip> 查当前 master_repl_offset 和 repl_backlog_size
• 预估业务峰值写入速率（例如：每秒 50KB 写入），若容忍最长断连 5 分钟，则缓冲区至少设为 50 * 60 * 5 = 15000 KB ≈ 15MB
• 在主节点配置中调大 repl-backlog-size（单位字节），并确保 repl-backlog-ttl 足够长（默认 3600 秒，即缓冲区空闲一小时才释放）
• 注意：repl-backlog-size 是内存占用，别盲目设到几百 MB；同时检查 maxmemory 是否有余量

手动触发部分同步失败怎么办？

如果从节点已启动但卡在同步状态，或你想绕过自动重试直接干预，可用 PSYNC 命令强制请求增量数据，但前提是主节点仍持有对应 offset 的日志：

• 先在从节点执行 ROLE 确认角色是 slave，再用 INFO replication 获取当前 master_repl_offset
• 登录主节点，查其 run_id（INFO server 输出的 run_id 字段）和当前 master_repl_offset
• 在从节点执行：PSYNC <master-run-id><offset></offset></master-run-id>，其中 offset 应略小于当前主节点 offset（比如减 100），否则可能因超出范围失败
• 若返回 FULLRESYNC，说明缓冲区确实没数据了，只能接受全量同步；返回 CONTINUE 则表示成功进入增量同步

从节点恢复后数据一定一致吗？

不一定。即使同步完成，也要警惕两类隐性不一致：

• 主节点故障前未及时传播到从节点的写操作（异步复制本质决定），这部分数据在故障转移后永久丢失，但从节点自身恢复过程不会报错
• 若从节点曾被人为设置为可写（slave-read-only no），且写入过数据，重启后这些脏数据不会自动清理，必须手动 FLUSHALL 或删掉数据目录再同步
• 验证方式：用 redis-cli --rdb <rdb-file> | wc -l</rdb-file> 对比主从 RDB 键数量（需先 BGSAVE 主节点），或用 redis-dump 工具导出哈希校验

真正麻烦的不是“同步不起来”，而是“看起来同步完了，其实差了几百条命令”——尤其在跨机房部署、网络抖动频繁的场景下，repl-backlog-size 和写入节奏的匹配，比重启操作本身更值得花时间算清楚。