集群状态为fail最直接原因是槽位未被在线主节点负责，即16384个槽中存在空缺或指向fail节点；需用cluster slots验证覆盖情况，CLUSTER FORGET清理失效节点，再分批执行CLUSTER ADDSLOTS安全补全。
集群状态为 fail，最常见、最直接的原因就是有 Slot 没被任何在线主节点负责——不是数据丢了，而是集群“不知道该让谁管”。只要 16384 个槽里有一个空缺，或指向一个已下线（fail 状态）的节点，CLUSTERDOWN 就会触发。
确认是否真有槽位缺失或指向失效节点
连上任一节点执行：
redis-cli -c -h {ip} -p {port} cluster slots
观察输出：
- 每行开头是槽范围，如
0 5460；后面跟着主节点 IP:端口 和 ID - 如果某行末尾是单个
-（比如12000 12999 -），说明这段槽完全未分配 - 如果某行指向一个 IP:端口，但用
cluster nodes | grep {node_id}查到它状态是fail或根本不在列表中，那就是“逻辑存在、物理离线”
再快速验总数是否凑够 16384：
把 cluster slots 输出保存为 slots.txt，运行：
awk '{sum += -+1} END {print sum}' slots.txt
结果不是 16384，就说明覆盖不全。
清理失效节点记录，确保目标节点可接收槽位
若发现有 fail 节点占着槽位，或你准备加槽的节点本身状态异常，必须先清理：
- 在所有节点上执行
CLUSTER FORGET {node_id}，清除对已下线节点的记忆 - 确保你要分配槽的目标节点已上线、握手成功：用
cluster nodes查它状态应为myself,master，不是fail或noaddr - 若该节点刚重启或重装过，可能本地槽表为空，需手动补；Redis 不会自动从其他节点同步槽分配
安全补全缺失槽位（不能一次全塞）
CLUSTER ADDSLOTS 只接受十进制整数列表，且单次不宜超过约 1000 个槽，否则易因协议解析失败而静默失败。
- 先连上目标节点：
redis-cli -c -h {target_ip} -p {target_port} - 分批执行，例如：
CLUSTER ADDSLOTS 0 1 2 ... 999CLUSTER ADDSLOTS 1000 1001 ... 1999
……依此类推，直到覆盖全部缺失段
每次执行后立即运行 cluster slots 或 cluster info 验证是否生效。若返回空或报错，说明节点尚未完成集群握手，需先检查网络连通性与 cluster meet 是否成功。
遇到 “Slot XXX is already busy” 怎么办
这不是错误，是冲突信号：该槽已被另一个节点声明归属。
- 先查谁占着：
cluster slots找出包含 XXX 的区间，记下对应节点 ID - 检查该节点是否存活：
cluster nodes | grep {id}；若状态为fail，就在所有节点执行CLUSTER FORGET - 若它还在线，且你确实要迁移，必须走标准流程：
CLUSTER SETSLOT {xxx} MIGRATING {target-node-id}，而不是强行ADDSLOTS
切忌在多个节点并发执行相同槽的 ADDSLOTS，这会让集群元数据彻底分裂，恢复难度陡增。
