增大repl-backlog-size能修复断连后全量回滚，因其为主节点提供足够大的环形缓冲区暂存断连期间的写命令；只要从节点重连时请求的slave_repl_offset仍在该缓冲区内（即master_repl_offset−slave_repl_offset≤repl_backlog_histlen），即可触发partialresync实现增量同步，避免fullresync。

为什么增大 repl-backlog-size 能修复断连后的全量回滚？

不是“增大就自动修复”，而是让主节点在从节点断连期间，把那些它还没来得及同步的写命令继续存进环形缓冲区；只要从节点重连时请求的 slave_repl_offset 还落在这个缓冲区的有效范围内，主节点就能返回 PARTIALRESYNC，跳过 RDB 生成和传输，直接发缺失的命令流。否则，主节点只能退化为 FULLRESYNC——这就是你看到的“全量回滚”。

怎么确认当前 repl-backlog-size 确实太小？

别猜，用数据比对：

• 在主节点执行：redis-cli INFO replication | grep -E "(master_repl_offset|repl_backlog_first_byte_offset|repl_backlog_size|repl_backlog_histlen)"
• 在从节点执行：redis-cli INFO replication | grep slave_repl_offset
• 计算差值：master_repl_offset - slave_repl_offset，如果该值 > repl_backlog_size，说明缓冲区已覆盖，增量同步必然失败
• 更关键看 repl_backlog_histlen：它才是当前缓冲区里还剩多少字节有效数据；若长期接近 repl_backlog_size，说明缓冲区几乎满载，风险极高

设多大才够用？别拍脑袋，按写入速率和断连容忍时间算

公式很直接：最小 backlog = 峰值写入带宽（B/s） × 最长可接受断连时间（s） × 1.2~1.5（冗余系数）。

Redis Skill - 高性能缓存管理

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

下载

• 测峰值写入带宽：用 redis-cli --stat 观察几轮高峰的 in= 值，或查监控中主节点网络入口流量（排除 TCP 包头等干扰后，取 Redis 协议层有效命令字节数）
• 定断连容忍时间：不是“希望它不断”，而是根据实际网络抖动历史、运维操作窗口、云厂商网络 SLA 综合判断，比如 90 秒或 180 秒
• 示例：实测主节点峰值写入 3.2MB/s，业务允许从节点最多离线 120 秒 → 最小建议值 = 3.2 × 1024 × 1024 × 120 × 1.3 ≈ 512MB → 配置 repl-backlog-size 536870912
• 注意：CONFIG SET repl-backlog-size 会立即重建缓冲区并丢弃旧数据，但不会持久化；务必同步改 redis.conf 并执行 CONFIG REWRITE 或手动保存

调大了还是触发全量同步？这些硬性条件绕不开

repl-backlog-size 只是必要条件，不是充分条件。以下情况哪怕 backlog 设到 2GB，照样强制全量：

• 主节点 run_id 变了：比如主节点重启、故障转移后新主节点 ID 不同，从节点 PSYNC 时带的旧 run_id 不匹配 → 直接 FULLRESYNC
• 从节点是首次连接，或执行过 SLAVEOF NO ONE 后又重连 → 没有上次的 offset 和 run_id 记录
• 主节点配置了 repl-diskless-sync yes，但 fork 子进程失败（vm.overcommit_memory=0 或内存不足）→ 降级为磁盘同步，过程中可能中断导致增量流程崩溃
• 网络闪断超过 repl-timeout（默认 60 秒），连接被主节点主动关闭 → 重连时旧连接上下文已销毁，offset 失效

真正容易被忽略的是：repl-backlog-first-byte-offset 这个起始偏移值。只要它大于从节点报上来的 slave_repl_offset，就代表那段数据早就被覆盖掉了，PSYNC 必败——这个细节在排查时经常被跳过。