主从复制链路是否真实建立需通过INFO replication中master_link_status及netstat确认，而非仅依赖CLUSTER NODES状态；复制与集群拓扑是两套独立机制。
主从复制链路是否真实建立
CLUSTER NODES 显示节点状态正常，不代表复制 TCP 连接活着。集群拓扑（Cluster Bus）和复制链路是两套独立机制。
常见错误现象：INFO replication 中 master_link_status:down，但 CLUSTER NODES 里该从节点仍显示 connected。
- 用
netstat -tnp | grep :6379（主节点监听端口）确认从节点 IP 是否有ESTABLISHED连接 - 检查主节点
tcp-keepalive配置，默认为0（禁用），NAT 或云环境易被中间设备静默断连 - 防火墙可能放行了 Cluster Bus 端口（如
16379），却拦截了复制端口（默认6379） - 从节点配置的
slaveof地址必须是主节点bind地址之一，不能是127.0.0.1或未绑定的网卡地址
PSYNC 命令失败是不是版本不兼容
PSYNC 返回 -ERR unknown command 不是配置问题，是协议不兼容——Redis 2.8 之前根本不支持该命令。
常见错误现象：主节点为 3.2，从节点为 2.6，执行 redis-cli -p 6379 PSYNC ? -1 直接报错。
- 先运行
redis-cli --version，主从双方都需 ≥ 2.8 - 若从节点无法升级（如遗留系统），只能降级使用
SYNC（全量同步，无增量能力） - Redis 4.0+ 默认禁用
SYNC，需在从节点配置中显式启用slave-serve-stale-data yes并重启
复制偏移量差值持续增大怎么办
延迟不是“卡住”，而是主从 repl_offset 差值不断拉大，说明增量同步跟不上写入节奏。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
常见错误现象：INFO replication 中 master_repl_offset 和 slave_repl_offset 差值每秒增长数百 KB 甚至 MB。
- 查主节点
repl_backlog_size和repl_backlog_active：若repl_backlog_active:0，说明 backlog 被关闭，所有重连都会强制全量 - 计算当前积压压力：
master_repl_offset - slave_repl_offset>repl_backlog_size→ 必然触发全量重同步 -
repl-backlog-size默认仅1mb，高写入场景建议设为写入峰值 QPS × 命令平均大小 × 60 - 从节点日志若频繁出现
Partial resynchronization not possible，就是 backlog 不够用了
全量同步卡在 RDB 传输阶段怎么定位
PSYNC 返回 FULLRESYNC 但后续没数据流，说明主节点已同意同步，但从节点没收到 RDB 文件。
常见错误现象：从节点 INFO replication 中 master_sync_in_progress:1 长期为 1；主节点日志无错误，但从节点磁盘无 dump.rdb 写入。
- 检查主节点日志是否有
Failed to write to RDB file或fork() failed - 确认从节点磁盘剩余空间 ≥ 主节点当前
used_memory_peak_human的 1.5 倍（RDB + AOF buffer） - 若主节点配置了
rdbcompression no，RDB 体积可能陡增，加剧网络/IO 压力 - 用
redis-cli --rdb /dev/null -u redis://host:port测试主节点 RDB 生成是否正常（不落地，只校验流程）
实际排查中最容易被忽略的是：主从节点的 requirepass 和 masterauth 配置不一致时，连接会静默失败，master_link_status 可能长期卡在 connecting，但不会报明显错误。务必逐项比对密码、bind、port、replica-read-only 等关键配置项。
