确认repl-backlog-size不够用需先验证三方面：repl_backlog_active必须为1；master_repl_offset与repl_backlog_first_byte_offset之差大于repl_backlog_size说明已覆盖；slave_repl_offset小于repl_backlog_first_byte_offset则必然全量同步。
怎么确认 repl-backlog-size 真的不够用
别一上来就改配置，先看 INFO replication 输出有没有硬证据。重点盯这三项：
-
repl_backlog_active: 1—— 必须是 1，为 0 表示缓冲区压根没分配（常见于主节点长期没连过从节点） -
master_repl_offset - repl_backlog_first_byte_offset > repl_backlog_size—— 如果成立，说明旧命令已被覆盖 slave_repl_offset —— 从节点要的数据已经不在缓冲区里了
再配合日志 grep Partial resynchronization not accepted 或 MASTER REPLICA sync started，频繁出现基本坐实 backlog 不足。
怎么算出该设多大：用峰值，不是平均值
公式就一个：repl-backlog-size ≥ 峰值写入速率（字节/秒） × 最大断连容忍时间（秒），但必须用「峰值」。
- 查峰值写入速率：用
redis-cli --stat观察 5–10 分钟内每秒最大流量；或从 Prometheus 抓redis_commands_total{cmd=~"set|lpush|hset|zadd"}的 rate，乘以平均命令大小（比如 200B） - 断连容忍时间不能只看网络抖动平均值，要翻最近一次从节点日志里
Connection with master lost到MASTER REPLICA sync started的间隔，取最大值 - 算完后上浮 30%–50%：比如峰值 4MB/s × 180 秒 = 720MB → 实际设
1073741824（1GB）更稳妥 - 单位全是字节：
128MB要写成134217728，不是128m或128000000
CONFIG SET 后为什么没生效
调了 CONFIG SET repl-backlog-size 1073741824，但 INFO replication 里 repl_backlog_histlen 还很低？可能卡在这几个环节：
- 配置未持久化：
CONFIG SET是运行时生效，重启就回退 → 必须同步改redis.conf并执行CONFIG REWRITE，或手动保存 - 缓冲区没重建：新配置只对后续新建的复制连接生效，已有从节点仍用旧缓冲区 → 必须让从节点执行
REPLICAOF no one再REPLICAOF重建握手 - 缓冲区根本没启用：即使改了配置，只要主节点从未成功建立过主从关系，
repl_backlog_active就是 0 → 可临时起一个从节点连上再断开，触发初始化
别忽略两个关键配套参数
单调大 repl-backlog-size 不够，还要看这两个是否协同：
-
repl-backlog-ttl：默认 3600 秒（1 小时）。它控制最后一个从节点断开后，缓冲区还能保留多久。超时释放后，新连上的从节点若需要已释放区间的 offset，照样全量同步 -
repl-timeout：主从心跳超时时间。如果太小（如默认 60 秒），网络抖动就容易误判断连，进而触发不必要的重连和 PSYNC 请求
真正容易被忽略的是：缓冲区大小不是越大越好。设得过大（比如几 GB）会常驻内存，且在从节点重建连接前，新配置不会真正接管数据流 —— 所以观察 repl_backlog_histlen 是否稳定在 repl_backlog_size 的 30%–70%，比盲目调大更重要。
