Redis为什么在主从断开重连后总是触发全量复制_监控并增大repl-timeout避免网络波动误判

因此，对于线上环境，建议将repl-timeout的起步值调整为240秒（即4分钟）。更稳妥的做法是，在压测时观察最差情况下的ACK延迟，并在此基础上增加50%的余量来设定最终值。

repl-backlog-size 不够也会间接导致全量复制

repl-backlog-size（复制积压缓冲区大小）和repl-timeout是联动的兄弟参数。即便连接幸运地没有被repl-timeout杀掉，如果从节点断开连接的时间过长，超过了repl-backlog缓冲区所能覆盖的命令窗口，那么重连时，从节点请求的复制偏移量就已经从缓冲区中被移除了，结果依然是退回到全量同步。

• 默认的repl-backlog-size = 1048576（即1MB），这个容量很小，通常只够支撑每秒几百KB的写入量持续1到2秒。
• 一个实用的估算公式是：repl-backlog-size ≥ 2 × 断连恢复平均耗时 × 平均每秒写入字节数。
• 举个例子：假设业务平均断连恢复需要8秒，期间主节点平均写入速度为5 MB/s，那么缓冲区至少需要设置为80 MB（可配置为83886080）。

这里有个关键点：repl-backlog是一个环形缓冲区，一旦写满，新的命令就会覆盖最旧的数据——它不会自动扩容，只会循环覆盖。所以，不能抱着“偶尔调大试试”的心态，必须根据业务峰值期的写入压力来一次性配置到位。

监控和验证是否真由 timeout 引发

排查问题时，不能只盯着“Connection lost”这类笼统的日志。真正需要关注的是从节点INFO replication命令输出中的几个关键字段：

• master_link_status:down —— 明确显示连接已断开。
• master_last_io_seconds_ago:62 —— 显示上次收发数据是在62秒前（如果这个值大于你设置的repl-timeout，就是重要线索）。
• sla ve_repl_offset和master_repl_offset的差值持续扩大 —— 这说明增量同步已经停滞，数据差距在拉大。

同时，检查主节点的日志，寻找是否有# Connection with sla ve X.X.X.X:XXXX timed out这样的记录。如果找到，且其时间戳与从节点显示的master_last_io_seconds_ago时间能对应上，那么基本可以锁定是repl-timeout误判导致的断开。

最后，调整参数后务必进行验证。可以在测试环境中，使用tc（Traffic Control）工具模拟网络丢包（例如执行命令：tc qdisc add dev eth0 root netem loss 5%），观察在模拟的恶劣网络条件下是否还会触发全量同步。否则，参数调了也可能白调。