cluster_state:fail是结果而非根因，需检查cluster_slots_assigned是否为0、cluster_size是否小于预期主节点数、cluster_slots_ok是否为0，并排查nodes.conf中IP配置错误或客户端未使用集群模式。
cluster info 里 cluster_state:fail 怎么快速定位真实原因
直接连任意节点执行 redis-cli -c -h <ip> -p <port> cluster info，别只看 cluster_state:fail 就慌——它只是结果，不是根因。重点盯三行：
-
cluster_slots_assigned是 0 或远小于 16384 → slot 没分配，集群空转，根本没真正“启动” -
cluster_size明显小于你预期的主节点数（比如本该有 6 个主，这里显示 1）→ 节点间完全没认全，大概率卡在初始握手阶段 -
cluster_state是fail但cluster_slots_ok为 0 → 不是节点挂了，是压根没完成 slot 划分
此时别急着重启或跑 redis-cli --cluster create，先查 cluster nodes 输出里有没有一堆 fail 或 noaddr 状态，那基本就是 IP/端口配置对不上。
nodes.conf 里写死的 IP 导致集群“失联”怎么清理
Redis 启动后会把监听地址写进 nodes.conf。如果迁移过虚拟机、改过宿主机 IP、或者用 Docker 换了网络模式，旧文件里存的还是老地址（比如 192.168.1.100），新环境节点互相 ping 不通，自然 cluster_size=1。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 停所有节点：
redis-cli -h <ip> -p <port> shutdown - 删每个实例数据目录下的
nodes.conf和dump.rdb（redis.conf保留） - 确认
redis.conf中已设cluster-announce-ip为当前机器真实 IP（严禁填127.0.0.1或0.0.0.0） - 再启动节点，重新执行
redis-cli --cluster create
客户端连得上但报 CLUSTERDOWN 的常见配置坑
工具如 RedisInsight 或 redis-cli -c 能 set 成功，不代表你的应用代码能用——它很可能用的是单节点客户端。
- Java 项目必须用
JedisCluster，不是Jedis；传入的节点列表要含至少 3 个主节点地址 - Go 项目用
redis.NewClusterClient()（go-redis/v8），不是redis.NewClient() - Python 用
redis.RedisCluster()，不是redis.Redis()；且初始化时加skip_full_coverage_check=True（若 slot 未 100% 分配） - 检查客户端日志是否反复重试连接某一个挂掉的节点 → 说明它没走集群拓扑发现逻辑，配置漏了或缓存了旧映射
法定多数失效：为什么明明有节点 running 还报 CLUSTERDOWN
CLUSTERDOWN 不是“某个节点 down”，而是集群判定自己无法维持一致性：在线且可通信的主节点数 ≤ 总主节点数 / 2。比如 6 主集群，只要 ≤ 3 个主节点存活，整个集群立即熔断。
- 用
redis-cli -c -h <ip> -p <port> cluster nodes | awk '$3 ~ /master/ && $3 !~ /fail|noaddr/ {count++} END {print "live masters:", count}'直接统计真实存活主节点数 - 别信
cluster info里的cluster_state:ok—— 它可能缓存旧状态，滞后于实际投票结果 - 注意
cluster-node-timeout（默认 15000ms）决定了“不可达”的判定窗口；节点状态同步有延迟，cluster nodes里标着fail的节点，可能已在其他节点视角下被踢出 quorum
Slot 缺失一定触发 CLUSTERDOWN，但 Slot 分配完整 ≠ 集群可用；哪怕所有节点都 running，只要有一个 slot 区间未分配（cluster slots 输出中某行结尾是 -），或指向一个 fail 节点，集群就拒绝服务。
