判断从节点同步完成的最直接依据是slave_repl_offset等于master_repl_offset且master_sync_in_progress为0，差值反映滞后程度，持续不缩小需排查网络、I/O或repl-backlog失效等问题。
用 INFO replication 查从节点同步偏移量
从节点恢复后，最直接的判断依据是复制偏移量是否追平主节点。执行 redis-cli -h <slave_ip> -p <slave_port> INFO replication</slave_port></slave_ip>，重点关注三个字段：slave_repl_offset（本从节点已复制的字节偏移）、master_repl_offset（主节点当前写入偏移）、master_sync_in_progress（是否正在全量同步）。只要 slave_repl_offset 等于 master_repl_offset 且 master_sync_in_progress 为 0，就说明同步已完成。
对比主从 master_repl_offset 和 slave_repl_offset
偏移量差值直接反映同步滞后程度。例如主节点返回 master_repl_offset:123456789，而从节点返回 slave_repl_offset:123456000，差值为 789 字节，说明只落后不到 1KB 数据——通常几毫秒内就能追上。但若差值达百万级或持续不缩小，可能是网络抖动、主节点写入压力过大，或从节点磁盘 I/O 瓶颈导致复制卡住。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 差值
- 差值 > 100000 且 30 秒内无变化：需检查从节点
redis.log中是否有Failed to write to RDB file或Connection reset by peer类错误 - 主节点
master_repl_offset长时间不增长：说明主节点已无写入，不是同步问题而是业务侧停写
用 redis-cli monitor 观察实时复制命令流
在从节点上执行 redis-cli -h <slave_ip> -p <slave_port> monitor | grep -E "(SET|INCR|DEL)"</slave_port></slave_ip>，能直观看到复制命令是否在持续到达。如果命令输出明显变慢或中断超过 5 秒，说明复制链路存在异常——常见于主节点启用了 repl-backlog-size 过小（默认仅 1MB），导致从节点断连重连时无法走增量复制，被迫触发耗时的全量同步。
- 不要在生产主节点上长期运行
monitor，它会显著拖慢性能 - 若看到大量
PSYNC失败后接SYNC，说明复制积压缓冲区已失效，正在做全量同步 - 观察到命令间隔突然拉长（如从 10ms 变成 500ms），优先排查从节点所在机器的 CPU 或磁盘使用率
集群模式下必须补查 CLUSTER NODES 的角色与状态
Redis Cluster 中节点可能“逻辑在线但复制异常”。即使 INFO replication 显示正常，也要执行 redis-cli -c -h <any_node> CLUSTER NODES</any_node>，确认该节点是否仍标记为 slave 角色，且其 master ID 是否指向当前有效的主节点 ID。曾有案例：从节点恢复后自动降级为孤儿节点（orphaned），role 显示 slave 但 master_id 是空或无效值，此时它根本没连上任何主节点，INFO replication 却显示 master_link_status:up ——这是 Redis 7.0+ 的一个已知状态缓存 bug，需手动执行 CLUSTER REPLICATE <valid_master_id></valid_master_id> 重置复制关系。
