master_link_status:down表明从节点已彻底断开与主节点的tcp连接，需先用telnet或nc验证网络连通性，再排查bind地址、protected-mode、requirepass与masterauth匹配、replicaof配置错误等；若连通但持续重连，则检查tcp-keepalive、repl-timeout及中间设备超时策略。
从节点 INFO replication 显示 master_link_status:down
这是最直观的断连信号，说明从节点已彻底失去与主节点的 TCP 连接。不要只看 role:slave 就以为复制还在跑——它可能卡在重连循环里。
先确认网络层是否通：在从节点机器上执行 telnet <master_ip><master_port></master_port></master_ip> 或 nc -zv <master_ip><master_port></master_port></master_ip>。不通就查防火墙、安全组、跨机房路由策略；通了但 master_link_status 仍为 down，重点检查主节点是否启用了 bind 配置绑定了 127.0.0.1 或内网不可达地址，以及主节点 protected-mode yes 是否在无密码时阻断了外部连接。
常见漏点：replicaof 指令中写错 IP（比如用了容器 hostname 但未配 DNS）、主节点开启了 requirepass 但从节点没配 masterauth，此时日志里会反复出现 Authentication required 错误，但 INFO replication 不报明文错误。
从节点状态为 connected，但 master_repl_offset 差值持续扩大
这代表链路“活着”，但数据在积压。差值 > 1MB 就该警惕，> 10MB 基本可判定同步失效。
优先查三件事：
-
repl-backlog-size是否太小？默认 1MB，高写入场景建议设为 256MB 起。用CONFIG GET repl-backlog-size确认，修改后需CONFIG REWRITE持久化 - 从节点 CPU/内存是否打满？
INFO server看used_cpu_sys和used_memory_human，OOM 或调度饥饿会导致命令回放卡顿 - 主节点是否存在慢查询？
SLOWLOG GET 5查最近 5 条慢命令，尤其是KEYS、大HGETALL、未加 LIMIT 的SCAN—— 它们会阻塞复制线程
从节点日志反复出现 Connection with master lost 后又自动重连
这是典型的“假连接”：TCP 握手成功，但 Redis 协议层握手失败或中途断开。比单纯连不上更难定位。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键线索藏在主节点日志里：tail -f redis-server.log | grep -i "slave\|repl"。高频出现 Client closed connection 或 Connection reset by peer，大概率是中间设备（如 SLB、NAT 网关）设置了短连接超时（常见 60s/300s），而 Redis 默认心跳间隔是 10s，但无业务流量时可能被静默 kill。
解决方法：
- 主节点配置
tcp-keepalive 60（单位秒），强制操作系统发保活包 - 从节点配置
repl-timeout 600，避免因瞬时抖动触发重连风暴 - 禁用任何对 Redis 复制流量做连接池或协议识别的中间件——Redis 复制协议不是标准 RESP，很多 LB 会误判并中断
集群模式下误用 SLAVEOF 导致槽位映射错乱
这是三主三从集群里最隐蔽的坑：你在某个从节点上手动执行 SLAVEOF <other_master_ip><port></port></other_master_ip>，它确实会变成那个节点的从库，但整个集群的 CLUSTER NODES 表不会更新，客户端仍按原哈希槽路由，结果读不到刚同步过来的数据，还可能因 MOVED 重定向失败报错。
正确做法只有两种：
- 运维级切换：用
CLUSTER FAILOVER（手动触发故障转移），或CLUSTER REPLICATE <node_id></node_id>（指定新主节点 ID），由集群自己维护元数据一致性 - 彻底退出集群：先
CLUSTER RESET HARD清空本地集群状态，再用SLAVEOF接入非集群主节点——但这已脱离 Redis Cluster 架构，仅适用于临时灾备
所有手动 SLAVEOF 操作前，务必 CLUSTER NODES 确认目标节点角色，且确保它不在当前集群拓扑内。否则你看到的“同步成功”，只是数据在错误的逻辑分片里安静地堆积。
