从节点重启后丢失run_id和offset是根本原因：二者成对缺失导致PSYNC请求被视作全新节点，触发全量同步；backlog过小或announce配置错误会进一步加剧该问题。
从节点重启后丢失 run_id 和 offset 是根本原因
Redis 增量复制依赖两个关键状态：主节点的 run_id（唯一身份标识）和从节点本地记录的复制偏移量 slave_repl_offset。从节点重启后，如果没持久化这两个值，重连时就会以空 run_id 和 offset=0 发起 PSYNC ? -1 请求——这在主节点看来等同于“全新从节点”，直接拒绝增量同步，走全量流程。
默认配置下 repl-backlog-size 太小加剧问题
即使从节点保留了 run_id 和 offset，若主节点的复制积压缓冲区太小，也撑不住重启窗口期的写入流量。常见现象是：从节点停 5 秒，主节点期间写了 2MB 数据，而 repl-backlog-size 仍为默认的 1MB，旧偏移量早已被覆盖。
-
redis-cli config get repl-backlog-size查当前值，生产环境建议设为至少 100MB（根据写入速率 × 预估最大中断时间估算） - 用
redis-cli info replication对比master_repl_offset和slave_repl_offset差值，若差值 >repl_backlog_size，必全量 -
config set修改立即生效，但必须同步写入redis.conf，否则重启后失效
从节点未启用 replica-announce-ip/replica-announce-port 导致心跳异常
在 Docker、K8s 或 NAT 环境中，从节点上报的 IP/端口可能不等于主节点实际能连通的地址。主节点收不到 REPLCONF ACK，触发 repl-timeout（默认 60 秒）后主动断连。从节点重启后重试连接，此时主节点已清空该从节点的 backlog 上下文，run_id 虽在，但偏移量无效，仍降级为全量。
- 检查从节点是否设置了
replica-announce-ip和replica-announce-port，确保与主节点网络可达 - 主节点日志出现
MISCONF Redis is configured to save RDB snapshots或频繁MASTER aborted replication时，优先排查此配置
info replication 输出里看不到 slave_repl_offset？那是从节点根本没完成过一次完整同步
刚执行 SLAVEOF 或配置生效后，从节点处于“连接中”或“正在加载 RDB”状态，info replication 里的 slave_repl_offset 字段可能为空或为 0。此时它还没开始真正追赶命令流，自然无法携带有效偏移量重连。
- 等待
role:slave且master_link_status:up出现后再观察slave_repl_offset - 用
redis-cli -h <master> info replication | grep offset</master>和redis-cli -h <slave> info replication | grep offset</slave>同时查，确认差值是否稳定收敛 - 别依赖从节点日志里 “SYNC with master” 就认为同步就绪——得看到偏移量持续增长才算真正进入命令传播阶段
