多久算断连
repl-timeout 默认 60 秒，定义主从之间多久没有有效交互就被判定为断连。判定超时后会触发重连，必要时回退到全量同步。在跨机房高延迟链路上，或者从库正在做耗时操作（大量写盘、执行重写）时，过小的取值会造成误判，表现为反复全量同步、主库频繁 fork，业务侧则看到周期性延迟毛刺。
基本信息
| 默认值 | repl-timeout 60（秒） |
|---|---|
| 触发后果 | 重连，无法增量续传时退化为全量同步 |
| 相关参数 | 复制心跳周期决定正常情况下的交互频率 |
| 观察字段 | master_link_status、sync_full、sync_partial_ok |
| 调整方向 | 高延迟或从库繁忙时适当放大 |
典型使用场景
- 跨机房主从出现周期性全量同步，评估超时值是否偏小
- 从库在做大量写盘时反复断连，需要区分是网络还是从库自身瓶颈
- 排查主库周期性 fork 与延迟毛刺，定位到复制层面的抖动
- 跨境或高延迟链路部署时按实测往返时间调整参数
- 为复制健康度设计告警时，明确断连判定的依据
查看与调整
查看与调整
redis-cli CONFIG GET repl-timeout
redis-cli CONFIG SET repl-timeout 120 # 高延迟链路适当放大
redis-cli INFO replication | grep -E 'master_link_status|master_last_io_seconds_ago'
redis-cli INFO stats | grep -E 'sync_full|sync_partial_ok' # 全量与增量同步次数
redis-cli CONFIG REWRITE # 写回配置文件现象与处置
| 现象 | 可能原因 | 处置方向 |
|---|---|---|
| 全量同步次数持续增长 | 网络抖动或超时值偏小 | 先看链路质量，再考虑放大超时 |
| 断连时间点与从库重写重合 | 从库自身 IO 繁忙导致响应迟滞 | 调整从库重写策略或错峰 |
| 主库周期性延迟毛刺 | 频繁全量同步带来的 fork 与传输 | 减少同类事件后观察毛刺是否消失 |
| 链路状态长期为 down | 网络不通或端口被拦 | 按网络故障排查，不要只调参数 |
放大超时的代价是故障发现变慢，主库真的挂掉时切换更晚，因此要配合链路状态告警一起使用，不能只靠超时值兜底。
参数调整前先看全量同步计数：如果它本来就很低，说明问题不在超时值，调参只是掩盖现象。