repl-backlog-size过小会直接触发全量同步；因其为环形缓冲区，从节点断连重连时若所需偏移量超出其覆盖范围，主节点无法提供增量数据，只能执行psync fullresync。
repl-backlog-size太小会直接触发全量同步
主节点的repl-backlog是环形缓冲区，只保留最近的写命令字节流。从节点断连重连时，靠master_repl_offset和自身slave_repl_offset算出要续传的偏移范围；一旦这个范围超出缓冲区当前覆盖范围，主节点就无法提供增量数据，只能走PSYNC fullresync——也就是全量同步。这不是网络问题，是缓冲区根本没存住那些命令。
典型现象包括：INFO replication里master_repl_offset - slave_repl_offset差值持续拉大、日志反复出现Partial resynchronization not accepted、从节点同步延迟飙升后突然重置为0。
怎么算出够用的repl-backlog-size值
核心公式是：缓冲区大小 ≥ 平均写入速率（字节/秒） × 最大断连容忍时间（秒），再上浮30%~50%留余量。
- 写入速率可从
INFO commandstats中估算：cmdstat_set、cmdstat_hset等高频命令的调用频次 × 平均单次命令字节数（例如1KB/set） - 断连时间不能看平均值，得查Redis日志里
Timeout waiting for data from master到下一条MASTER REPLICA sync started之间的最大间隔 - 多个从节点时，按最不稳定那个来定——比如某个从节点因跨机房网络抖动最长断连过120秒，那就得按120秒算
举例：主节点每秒写入约1.5MB（1572864 字节），要求断连5分钟内不丢增量，则最低需 1572864 * 300 = 471859200 字节 ≈ 450MB，建议设为600000000（约572MB）。
CONFIG SET之后为什么没生效
调大repl-backlog-size后内存没涨、INFO replication里repl_backlog_active仍为0，说明缓冲区根本没启用。Redis只在至少有一个从节点成功完成过一次同步后才分配该缓冲区——哪怕那个从节点当前已断开。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
验证和修复方法：
- 执行
INFO replication，确认输出含repl_backlog_active:1；若为0，说明缓冲区未激活 - 临时起一个测试从节点连上主节点，等它完成一次完整同步后断开，即可触发主节点初始化
repl-backlog - 修改后必须让所有从节点重建复制连接：先
REPLICAOF no one，再REPLICAOF <host><port></port></host>，否则仍用旧缓冲区 -
CONFIG SET repl-backlog-size不会持久化，务必同步更新redis.conf并执行CONFIG REWRITE
repl-backlog-ttl和repl-backlog-size要一起调
即使repl-backlog-size足够大，如果repl-backlog-ttl（默认3600秒）太短，最后一个从节点断开一小时后缓冲区就被释放。下次有从节点连上来，哪怕只断了10秒，也因缓冲区为空而强制全量同步。
应对策略：
- 对频繁短时断连的场景（如滚动升级、网络抖动），把
repl-backlog-ttl设为36000（10小时）比盲目堆大repl-backlog-size更有效 -
repl-backlog-ttl只影响“空闲期”，不影响缓冲区容量本身；两者配合才能提高增量同步成功率 - 注意：过大的
repl-backlog-size会常驻占用内存，尤其当长期无从节点时——此时repl-backlog-ttl才是控制内存释放的关键
真正容易被忽略的是：缓冲区是否激活、从节点是否重建连接、以及repl-backlog-ttl是否匹配你的断连模式。光改一个数字，不检查这三点，等于白调。
