Redis主从频繁全量复制？别急着怀疑数据，先看看这个参数
遇到Redis主从断开重连后频繁触发全量复制，很多人的第一反应是数据同步出了问题。但真相往往更简单：大概率不是数据丢了，而是那个关键的repl-timeout参数设置得太小，连接被偶发的网络抖动给“误杀”了。
repl-timeout 被触发的三种真实场景
这里有个常见的误解：repl-timeout并非仅仅指“主从同步超时”。实际上，它是三类通信行为的统一兜底时限，任何一个场景超时都会导致连接关闭：
- 场景一：数据传输卡顿。 从节点视角，在
repl-timeout规定的时间内，没能收到主节点发来的RDB文件数据或后续的增量命令，比如SYNC过程被意外设起。 - 场景二：心跳有去无回。 同样是从节点视角，连续一段时间没有收到主节点发来的
REPLCONF ACKping包（即主节点主动发心跳，但从节点没收到回应）。 - 场景三：心跳有来无往。 切换到主节点视角，如果连续收不到从节点回复的
REPLCONF ACK确认包（即从节点该回ping，但主节点等不到），也会触发超时。
只要满足上述任意一种情况，连接就会被立刻关闭。之后从节点重连，往往会因为复制偏移量（offset）失效或复制ID（replication ID）不匹配，被迫走FULLRESYNC全量同步。日志里通常会留下这样的证据：
23456:M 10 Jan 2025 03:16:23.456 # Timeout connecting to the MASTER
需要特别注意的是：这种断开是Redis在应用层自己主动关闭的，并非底层TCP连接断了。也就是说，TCP连接可能依然健在，但Redis已经单方面判定双方“失联”了。
为什么默认 60 秒在生产环境大概率不够
默认的60秒听起来不短，但在真实的生产网络环境中，却常常捉襟见肘。按照默认配置，主从之间每10秒（repl-ping-sla ve-period默认值）会交互一次ACK心跳。然而，在实际的网络链路中，丢包、延迟毛刺、容器网络抖动或是云厂商VPC的延迟波动，都可能让单次ACK的往返时间（RTT）飙升到30到50秒。关键在于，repl-timeout计算的是“累计未通信时间”，而非某一次请求的延迟。
- 如果设置不当，比如
repl-timeout ≤ repl-ping-sla ve-period × 2- 对于内存较大的实例（比如超过10GB），在执行RDB的bgsa ve时，主进程的写入可能被阻塞，再加上fork子进程的开销，ACK响应延迟几十秒是常有的事。
- 此外，像Kubernetes Pod重建、Service Mesh sidecar注入、或是云平台SLB的健康检查干扰，都可能让ACK包暂时“迷失方向”。
因此，对于线上环境，建议将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%），观察在模拟的恶劣网络条件下是否还会触发全量同步。否则，参数调了也可能白调。
