主从复制健康需综合判断lag、offset及master_repl_offset/slave_repl_offset一致性：lag≥5或持续为-1、offset长期停滞、connected_slaves异常减少均表明同步不可靠。
主从复制是否健康，不能只看 state=online —— 它可能“在线但脱节”。真正要盯的是 lag、offset 和主从 master_repl_offset/slave_repl_offset 的一致性。
怎么看从节点是否真的跟上了主节点
执行 INFO replication 后，重点不是找 role:slave，而是定位到类似这样的行：
slave0:ip=172.16.0.78,port=6379,state=online,offset=6855559604,lag=1
其中 lag=1 表示从节点最后一次上报进度后，主节点又产生了约 1 秒的写入增量——这属于正常范围；但若 lag 持续 ≥5，说明同步已明显滞后。注意：lag 是秒级估算值，不是精确延迟，它依赖从节点定时发来的 REPLCONF ACK 心跳，网络抖动或从节点忙于加载 RDB 都会导致该值跳变。
-
offset是从节点当前已应用的复制偏移量（字节），必须和主节点的master_repl_offset尽量接近 - 若
lag为 -1，通常表示从节点未发送过ACK，可能是刚连上、网络不通或主节点拒绝认证 - 多个从节点时，每个
slaveN:行都要单独检查，不能只看第一个
主节点上怎么验证所有从节点是否同步一致
在主节点执行 INFO replication，关注三类字段：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
connected_slaves:2—— 实际连接数，不等于配置数；断连后不会自动重试，需查日志确认原因 -
master_repl_offset:6855559604—— 主节点当前总复制偏移量，所有从节点的offset都应 ≤ 此值 -
slave0...slaveN列表中的offset值 —— 若某个从节点的offset长期卡住不动，而其他节点正常增长，大概率该从节点 I/O 阻塞或磁盘满
特别注意：如果主节点输出里没有列出某从节点（即使它显示 state=online），说明主节点已将其踢出连接列表，常见于 repl-timeout 超时或 min-slaves-to-write 触发保护机制。
lag=0 真的代表完全实时吗
不是。lag=0 只表示“从节点上次上报时，主节点刚好没新写入”，但下一毫秒就可能产生新命令。它不反映网络传输耗时、命令执行耗时或从节点本地命令队列积压情况。
- 真正衡量数据一致性，应比对主节点的
master_repl_offset和从节点的slave_repl_offset（在从节点INFO replication中）——二者差值越小，数据越接近一致 - 若差值持续 > 10000 字节，且
lag波动大，说明增量同步链路存在瓶颈（如主节点写入太快、从节点 CPU 不足、TCP 窗口受限） -
lag在从节点重启或全量同步后会短暂为 -1，属正常；但若恢复后长期为 0 且offset不增长，则可能是复制被意外中断（例如SLAVEOF NO ONE被误执行）
哪些指标异常时必须立刻干预
以下任意一项出现，基本意味着主从已不可靠，不能用于读写分离或故障切换：
- 从节点
state显示connecting或err，且持续超过 30 秒 -
lag > 60并持续 5 分钟以上（尤其在低流量时段仍如此） - 主节点
connected_slaves突然减少，且对应从节点日志中出现Connection refused或NOAUTH - 从节点
INFO replication中master_host为空，或master_link_status:down
最易被忽略的一点：监控脚本若只采集 lag 单一指标，会漏掉 offset 停滞这类静默故障——必须同时采集并比对主从两端的偏移量差值。
