clusterdown本质是集群未达最小服务单元,需至少3个主节点在线且16384个slot完整分配;先执行cluster info查cluster_state:fail、cluster_slots_assigned是否为0或远小于16384、cluster_size是否小于预期主节点数,再结合cluster nodes检查fail/noaddr状态及nodes.conf中ip是否匹配当前真实地址。

CLUSTERDOWN 报错本质是集群无法提供最小服务单元 —— 至少要有 3 个主节点在线且 slot 分配完整,否则任何客户端请求都会直接失败。
cluster info 显示 cluster_state:fail 怎么快速定位
先连任意一个节点执行 redis-cli -c -h <ip> -p <port> cluster info</port></ip>,重点看三行:
-
cluster_state:fail—— 集群未激活,不是“down”而是根本没起来 -
cluster_slots_assigned:0或远小于16384—— slot 没分配,集群空转 -
cluster_size:0或小于预期主节点数 —— 节点互相没认全,网络或配置堵在第一步
此时别急着重启,先查 cluster nodes 输出里有没有大量 fail 或 noaddr 状态,那基本是 IP/端口配置没对上。
nodes.conf 里 IP 写死导致集群“失联”
Redis 启动后会把实际监听地址写进 nodes.conf。如果用 Docker、VM 迁移或改过宿主机 IP,旧 nodes.conf 里存的还是老 IP(比如 192.168.1.100),新环境节点就互相 ping 不通。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 停所有节点:
redis-cli -h <ip> -p <port> shutdown</port></ip> - 删每个实例数据目录下的
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 项目用
go-redis/v8的redis.NewClusterClient(),不是redis.NewClient() - Python 用
redis.RedisCluster(),不是redis.Redis();且初始化时要加skip_full_coverage_check=True(若 slot 未 100% 分配) - 检查客户端日志是否反复重试连接某一个挂掉的节点 —— 这说明它没走集群拓扑发现逻辑,配置漏了
slot 分配不均或缺失导致 cluster_slots_ok
即使所有节点都 running,只要有一个 slot 没被任何主节点接管,cluster_slots_ok 就会卡在小于 16384,状态永远 fail。
- 用
redis-cli -c -h <any-node> cluster slots</any-node>查哪些 slot 区间没被覆盖 - 如果输出里有空缺(比如只看到
0-5460和10923-16383),说明创建集群时没指定足够节点或中途失败 - 不要手动
cluster addslots—— 容易错,直接删配置重来更稳 - 重创建时确保命令里列出全部 6 个节点(3 主 3 从),且结尾加
--cluster-replicas 1
真正麻烦的从来不是报错本身,而是 nodes.conf 里那一行静态 IP —— 它不会自动更新,也不会告诉你哪里错了,只默默让整个集群变成一座孤岛。










