Redis集群缩容报错节点不为空 需先迁移所有槽位再下线

在 Redis 集群进行缩容操作时，最令人头疼的报错莫过于：ERR Target node is not empty. All slots must be covered by other nodes。这句错误信息直白地揭示了问题所在——目标节点仍然持有部分槽位（slot），导致集群拒绝将其移除。Redis 集群采用严格的元数据一致性机制：只要该节点上执行 CLUSTER SLOTS 返回非空结果，del-node 命令就会直接失败，毫无商量余地。

ERR Target node is not empty. All slots must be covered by other nodes 的含义

这条报错是 redis-cli --cluster del-node 执行时最常遇到的阻碍。通俗来说，就是目标节点仍然占据着至少一个槽位，Redis 集群因此拒绝将其移除。集群的元数据强一致性机制决定了：只要 CLUSTER SLOTS 在该节点上返回非空结果，del-node 就会直接失败，没有任何变通余地。

为什么 reshard 迁移完成后，旧节点仍可能显示有槽位

发出迁移命令并不等于迁移完成——这个坑很多人踩过，常见卡点包括：

• 在 redis-cli --cluster reshard 交互式流程中，错误地填写了 host:port 而非 40 位 node id，导致目标节点状态卡在 IMPORTING，源节点卡在 MIGRATING，槽位实际未完成归属变更
• 迁移过程中客户端持续写入，且未正确处理 ASK 或 MOVED 重定向，造成部分 key 仍滞留在旧节点
• 执行完 reshard 后立即查询 CLUSTER SLOTS，未等待集群配置更新传播完成（通常需要 1–2 秒的延迟）

验证是否真正清空的方法很简单：连接旧节点执行 CLUSTER SLOTS，必须返回 []；再连接任意其他节点执行 CLUSTER NODES，确认旧节点状态为 fail? 或已彻底消失。

del-node 成功后，为什么旧节点进程仍在运行

del-node 只是让集群“忘记”这个节点，并不会关闭进程、删除数据或清理磁盘。你需要手动执行以下操作：

• 登录旧节点所在机器，执行 redis-cli -p shutdown（或 kill 对应进程）
• 如果使用 Docker 部署，需执行 docker stop 容器，不能仅删除节点元数据
• 客户端连接池需要主动刷新：旧连接仍可能指向已下线节点 IP，导致请求超时或写入数据丢失，必须重新加载或重启应用

跳过这一步，等于留下了一个“幽灵节点”——表面下线，实际仍在响应请求，但数据却无人接管。

残留 key 如何清理，FLUSHALL 能否直接使用

即使 CLUSTER SLOTS 返回空，旧节点上仍可能存在残留 key（例如迁移中断、客户端绕过重定向直连写入等情况）。此时不能使用同步阻塞的 FLUSHALL，尤其是在生产环境：

• 应使用 FLUSHALL ASYNC 或逐库执行 FLUSHDB ASYNC，避免阻塞主线程
• 先连接旧节点执行 DBSIZE 和 KEYS *（仅适用于开发环境或小数据量）来确认残留 key 的量级
• 若节点已无业务流量，可先执行 CLIENT KILL TYPE normal 清除所有非 pub/sub 连接，再执行 flush

真正安全的缩容流程，不是“把槽位迁走就结束”，而是“确认槽位已空、key 已空、进程已停、客户端连接已断”。少一步，都可能让你在半夜收到报警。