增大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 必败——这个细节在排查时经常被跳过。
