repl-backlog-size决定断连后能否部分同步，非防全量开关；若master_repl_offset−slave_repl_offset＞repl_backlog_size，则缓冲区溢出必触发全量同步；应设为峰值写入带宽×断连容忍时长并预留20%余量。
repl-backlog-size 不能阻止全量复制发生，只决定断连后能否走部分重同步（PSYNC）。它不是“防风暴开关”，而是“缓冲窗口大小”——窗口太小，从节点一断就掉出范围，必然触发全量同步；窗口够大，才有可能把断连期间的增量命令兜住。
怎么判断当前 repl-backlog-size 是否太小
关键看三个值是否持续“对不上”：
-
master_repl_offset（主节点当前总偏移量） -
slave_repl_offset（从节点上报的最新偏移量） -
repl_backlog_size（当前积压缓冲区大小）
如果 master_repl_offset - slave_repl_offset > repl_backlog_size，说明从节点断连期间主节点写入的数据已超出缓冲区容量，旧数据被覆盖，PSYNC 必然失败，只能全量同步。
实操建议：
- 用
redis-cli -h {master} INFO replication | grep -E "(master_repl_offset|slave_repl_offset|repl_backlog_size|repl_backlog_first_byte_offset)"实时抓取 - 重点观察
repl_backlog_first_byte_offset：若该值 > 从节点记录的 offset，说明起始位置已丢失，PSYNC 不可能成功 - 运维巡检时可写脚本每5分钟比对一次，差值连续3次超阈值即告警
如何估算安全的 repl-backlog-size 值
它不是拍脑袋设的，而是业务容忍断连时长 × 主节点峰值写入带宽。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
例如：
- 业务允许从节点最多断连 90 秒
- 主节点在大促期间写入峰值达 3.2 MB/s（可通过
INFO commandstats中cmdstat_set:calls和平均 value 大小粗估，或用redis-cli --latency-history -i 1结合网络监控交叉验证） - 则最小需设为
3.2 * 90 = 288MB，再加 20% 余量 → 推荐CONFIG SET repl-backlog-size 350000000
注意：repl-backlog-size 单位是字节，不是 MB；设为 350000000 比 350mb 更稳妥，避免某些 Redis 版本解析失败。
调大后为什么还是触发全量同步
常见错误现象包括：
- 从节点日志反复出现
Partial resync not possible (no cached master) -
INFO replication显示repl_backlog_active:0（说明缓冲区根本没启用） - 主节点
repl_backlog_histlen长期为 0 或极小值
原因和对策：
- 主节点没有活跃从节点连接 →
repl-backlog-size只在首个从节点连接后才真正分配并填充，空跑配置无效 - 从节点配置了
repl-timeout过短（如 10s），网络抖动即断连 → 必须配合调大repl-timeout（建议 ≥ 60），否则还没等 PSYNC 发起就已超时断开 - 主节点内存不足，
CONFIG SET成功但实际未生效 → 检查INFO memory中used_memory_rss是否接近上限，Redis 不会因 OOM 自动缩容 backlog - 云厂商限制：阿里云 ApsaraDB 最高仅支持
1048576000（1GB），设更大值会返回ERR Invalid argument
真正容易被忽略的是：哪怕 repl-backlog-size 设得再大，只要从节点网络不稳定、频繁假死、或主节点本身 client-output-buffer-limit replica 触发强制断连，就永远卡在“想部分同步却连不上”的循环里。这时候光调参数没用，得先稳住网络或换用 Sentinel / Cluster 架构兜底。
