主从同步断开时repl-backlog溢出会导致全量同步反复触发；需根据写入速率与最大重连时间估算合理大小，动态调整后须同步更新配置文件。
主从同步断开时看 repl-backlog 是否溢出
Redis 主从频繁断连，尤其在从节点短暂网络抖动或重启后无法追上主节点，大概率是 repl-backlog 缓冲区太小、被覆盖导致全量同步反复触发。此时主节点日志里常出现类似 Connection with slave xxx lost, repl_backlog is full 或从节点报 Partial resynchronization not possible (no cached master)。
判断依据很简单：查主节点当前 backlog 状态：
redis-cli info replication | grep -E "(repl_backlog_active|repl_backlog_size|repl_backlog_histlen)"
repl_backlog_histlen 接近 repl_backlog_size 且长期高位运行，基本可确认溢出风险高。
怎么设合理的 repl-backlog-size
这个值不是越大越好，也不是拍脑袋定。它本质是主节点为部分重同步保留的最近写命令缓冲区，单位字节。设太小容易溢出，设太大浪费内存（尤其主节点写入不高的场景）。
- 估算公式：
repl-backlog-size = max_write_per_second × expected_max_reconnect_time_in_seconds × 2 -
max_write_per_second可用INFO commandstats中cmdstat_set:calls=xxx类指标粗估，或用redis-cli --stat观察峰值 QPS -
expected_max_reconnect_time指从节点最可能断连多久——比如运维升级耗时、跨机房网络波动窗口、K8s Pod 重建周期等，建议至少留 5–10 分钟余量 - 默认值
1mb仅适合低流量本地环境；生产环境常见设为64mb～256mb，但必须结合实际写入节奏校准
改完配置后必须重启主节点？
不用。Redis 支持运行时动态调整：
redis-cli config set repl-backlog-size 134217728
注意：134217728 是 128MB（即 128 × 1024 × 1024），单位必须是字节。该命令立即生效，新 backlog 区域会重建，旧数据丢弃。
但要注意：
- 该配置不会持久化到
redis.conf，重启后恢复原值 → 务必同步修改配置文件并config rewrite或手动更新 - 调整后观察
repl_backlog_histlen是否稳定在repl_backlog_size的 30%–70%，过高说明仍偏小，过低说明冗余 - 如果从节点已处于全量同步中，本次调整不影响当前同步流程，只影响后续断连恢复行为
还有哪些情况会让 repl-backlog 失效
即使 backlog 足够大，以下情况仍会导致部分重同步失败，需一并排查：
- 主节点启用了
replica-serve-stale-data no且从节点断连期间主节点发生故障转移（如哨兵切换），新主节点没有旧主的 backlog 历史 - 主节点设置了
repl-backlog-ttl 0（默认值），但长时间无从节点连接，backlog 会被自动释放 → 检查repl_backlog_active是否为0 - 从节点
slave-priority设为0，被哨兵判定为不可用，间接导致同步链路中断 - 主节点写入含大量 bigkey（如超大
HSET或LPUSH），单条命令就占满 backlog 缓冲区 → 这种场景下增大 size 效果有限，得拆 key 或限流
缓冲区大小只是同步稳定性的一环，真正关键的是把「断连时长」和「写入速率」这两个变量控制在可预期范围内。否则再大的 backlog，也扛不住一次持续十分钟的网络分区。
