主从同步突然变成全量复制，大概率因从节点偏移量超出主节点复制积压缓冲区范围；可通过info replication比对master_repl_offset、repl_backlog_first_byte_offset和repl_backlog_size判断是否缓冲区循环覆盖，再结合run_id是否变更、是否首次连接等排查。
为什么主从同步突然变成全量复制？
Redis 主从切换或断连重连后频繁触发 SYNC 或 PSYNC 全量同步，大概率不是网络抖动导致，而是从节点的复制偏移量（slave_repl_offset）已超出主节点的复制积压缓冲区（repl_backlog）覆盖范围——换句话说，主节点早把从节点“想追”的那部分命令丢掉了。
怎么确认是 repl-backlog-size 不够？
直接查主节点当前积压缓冲区状态：
redis-cli info replication | grep -E "repl_backlog_active|repl_backlog_size|repl_backlog_first_byte_offset|master_repl_offset"
关键看三组值是否匹配：
-
repl_backlog_active为1（说明缓冲区启用） -
master_repl_offset - repl_backlog_first_byte_offset > repl_backlog_size→ 缓冲区已循环覆盖，旧命令丢失 - 从节点执行
INFO replication，对比其slave_repl_offset和主节点的repl_backlog_first_byte_offset：若前者<后者，就注定要全量同步
repl-backlog-size 设多大才够用？
不能拍脑袋填，得按写入压力和从节点断连容忍时长估算：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先用
redis-cli --stat或监控工具观察峰值写入带宽（如每秒写入 2MB 命令数据） - 确定最长可接受的从节点离线时间（比如 5 分钟），则最小建议值 = 峰值写入速率 × 离线容忍秒数
- 例如：2MB/s × 300s = 600MB → 配置
repl-backlog-size 629145600（单位字节） - 生产环境建议再上浮 20%~50%，避免临界波动；但也不宜过大（内存占用 + 复制缓冲区是单实例全局一份）
修改后需重启 Redis 或用 CONFIG SET repl-backlog-size xxx 生效（注意该命令不持久化，记得同步改 redis.conf）。
还有哪些情况会绕过增量同步强制全量？
repl-backlog-size 只是常见原因，别忽略这几个硬性条件：
- 主节点运行 ID（
run_id）变更：重启、故障转移后新主节点 ID 不同，从节点无法匹配旧run_id，直接退化为全量 - 从节点首次连接（无
master_repl_offset记录）或执行了SLAVEOF NO ONE后又重连 - 主节点配置了
repl-diskless-sync yes，但子进程 fork 失败（如内存不足、vm.overcommit_memory=0），降级为磁盘同步并可能中断增量流程 - 网络闪断时间超过
repl-timeout（默认 60 秒），连接被主动关闭，重连时偏移量已失效
排查时优先看主从双方的 run_id 是否一致、slave_repl_offset 是否持续落后、以及日志里有没有 Partial resynchronization not accepted 这类明确提示。
