调大 repl-backlog-size 后全量复制增多，是因为 repl-backlog-ttl 默认为0导致旧数据堆积、挤占新命令空间，使从节点所需偏移量被覆盖；应设合理 ttl（如3600）并按写入速率×断连时间估算 size。
为什么 repl-backlog-size 调大后全量复制反而变多了？
调大 repl-backlog-size 本意是延长从节点断线重连时的增量同步窗口，但实际中常出现调大后全量复制更频繁——根本原因是缓冲区虽大，但 repl-backlog-ttl 默认为 0（永不过期），导致 backlog 持续累积旧数据，挤占新写入命令的空间。Redis 5.0 的复制积压缓冲区是环形结构，一旦新写命令覆盖了从节点所需的偏移量范围，就会触发全量同步。
- 检查当前 backlog 使用情况：
INFO replication中关注repl_backlog_active、repl_backlog_size、repl_backlog_first_byte_offset和repl_backlog_histlen -
repl-backlog-ttl应设为合理值（如 3600），避免无效数据长期驻留；该参数在 Redis 5.0+ 才生效，低版本需靠 size + 主动监控控制 - 真正决定能否增量同步的是：从节点断连期间主节点写入量是否超过
repl_backlog_histlen，而非repl-backlog-size的绝对值
如何估算合理的 repl-backlog-size？
不能拍脑袋设 100MB，要基于主节点的写入速率和从节点可能的最长断连时间来算。Redis 5.0 不提供内置写入速率统计，得靠外部观测或 INFO commandstats 估算 QPS 再结合平均命令大小反推字节数。
- 用
redis-cli --stat在高峰期观察每秒写入流量（单位 KB/s） - 假设峰值写入为 2MB/s，预期从节点最多断连 60 秒，则最小 backlog 需 ≥ 2 × 1024 × 60 ≈ 120MB
- 再上浮 30% 容错，设为 160MB；同时确认
repl-backlog-ttl设为 3600，防止长期空载导致 buffer 膨胀却无实效 - 注意：过大的 backlog 会占用主节点内存且不释放（即使没数据），对内存敏感场景要权衡
主从断连后到底走 PSYNC 还是 FULLRESYNC？
Redis 5.0 默认使用 PSYNC2 协议，但能否成功增量同步，取决于三个条件是否同时满足：从节点上报的 run_id 与主节点一致、上报的 offset 在当前 backlog 有效范围内、主节点 backlog 未被重置（如执行了 DEBUG RELOAD 或重启）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 查看从节点日志中是否出现
Connecting to MASTER后紧跟MASTER REPLICA sync: receiving streamed RDB—— 这是全量复制的明确信号 - 若看到
Partial resynchronization not possible (no cached master)，说明主节点已丢失该 run_id 的上下文，常见于主节点重启或手动CONFIG SET repl-backlog-size 0 - 从节点执行
ROLE可查当前复制状态；主节点执行ROLE可看有哪些从节点及它们的 offset 偏移量
哪些操作会意外清空 repl-backlog？
除了主节点重启，以下操作也会让 backlog 彻底失效，导致下一次重连必走全量：
- 执行
CONFIG SET repl-backlog-size 0（哪怕之后再调大，旧 backlog 已丢） - 主节点执行
DEBUG RELOAD（加载 RDB 时重置复制状态） - 手动
SLAVEOF NO ONE将主节点降级为独立实例（backlog 被清空） - 注意：
CONFIG REWRITE不影响 backlog，但修改配置后未持久化，重启仍会丢失
backlog 是内存中的运行时结构，不落盘。所有依赖它的增量同步逻辑都建立在“主节点持续在线且配置稳定”的前提上，这点容易被忽略。
