集群故障排查（CLUSTERDOWN）是什么
Redis Cluster 报 CLUSTERDOWN 通常有两种原因：槽没有全部被覆盖，或者多数主节点不可达导致集群失去法定票数。排查顺序是固定的——先看 CLUSTER INFO 的 cluster_state 与槽分配统计，再看 CLUSTER NODES 的节点角色与 fail 标记，最后确认是网络分区、节点宕机还是槽迁移没做完。集群操作不可回退，动手前先保存现场信息。
基本信息
| 适用版本 | Redis 3.0+ Cluster；命令名在 5.0 前后一致 |
|---|---|
| 核心命令 | CLUSTER INFO、CLUSTER NODES、CLUSTER SLOTS、redis-cli --cluster check |
| 状态字段 | cluster_state（ok/fail）、cluster_slots_assigned、cluster_known_nodes |
| 默认行为 | cluster-require-full-coverage yes 时有槽缺口则整体停止服务 |
| 客户端要求 | 集群模式客户端需支持 MOVED/ASK 重定向（redis-cli 加 -c） |
| 高危命令 | CLUSTER RESET 会清除节点身份与数据 |
典型使用场景
- 业务报 CLUSTERDOWN：判断是槽缺口还是多数主节点失联
- 扩容或缩容后槽迁移残留：找出未分配或仍处于迁移状态的槽
- 节点故障恢复：确认故障节点归位后集群状态是否自动恢复
- 客户端连接异常：确认是否因为没有开启集群模式而误判为实例故障
- 变更前体检：用 --cluster check 做迁移与升级前的健康核对
诊断命令
诊断命令
# 集群整体状态：cluster_state / 槽覆盖 / 已知节点
redis-cli -c CLUSTER INFO
# 节点清单：角色、负责的槽、fail 与 handshake 状态
redis-cli -c CLUSTER NODES
# 体检（推荐，输出更易读）
redis-cli --cluster check 10.0.0.1:6379
# 查看槽分配明细
redis-cli -c CLUSTER SLOTS | head
# 客户端连接必须带 -c，否则会因 MOVED 误判为故障常见修复动作（确认根因后执行）
常见修复动作（确认根因后执行）
# 1) 新节点未入集群：手动握手
# CLUSTER MEET <ip> <port>
# 2) 迁移卡住收尾：把槽置为 STABLE
# CLUSTER SETSLOT <slot> STABLE
# 3) 未分配的槽重新指派（在目标节点执行）
# CLUSTER ADDSLOTS <slot...>
# 4) 自动修复（谨慎，先备份现场）
redis-cli --cluster fix 10.0.0.1:6379关键字段读法
| 字段 | 含义 | 异常判断 |
|---|---|---|
| cluster_state | 集群可用状态 | fail 常见于槽未全覆盖或多数主节点不可达 |
| cluster_slots_assigned | 已分配槽数量 | 小于 16384 说明有槽缺口 |
| cluster_known_nodes | 已知节点数量 | 少于预期说明节点未加入或已失联 |
| cluster_size | 提供槽的主节点数 | 与预期不符说明角色错乱 |
| require-full-coverage | 槽缺口是否全局停止服务 | yes 时一个分片故障会影响整个集群 |
排查前先保存现场：把 CLUSTER NODES 输出与各节点配置文件复制一份留档，集群操作几乎没有回退路径，改错一步可能需要几小时重建；这也是变更评审要求「先证据后动作」的原因。
CLUSTER RESET 会清除节点身份与数据，生产环境禁止随手执行；另外忽略了 cluster-require-full-coverage=yes 的语义，容易误以为「坏一个分片只影响部分数据」，实际该配置下全集群都会拒绝服务。