CLUSTER RESET不能让节点“回到出厂状态”，仅清本地元数据；仅适用于物理下线节点清理缓存、测试环境清空无槽节点、或修复网络分区后清除故障标记。
不能直接用 CLUSTER RESET 让节点“回到出厂状态”——它只清本地集群元数据，不删数据、不退群、不重置配置文件，误用反而会导致槽位错乱或集群不可用。
什么时候该用 CLUSTER RESET
仅适用于以下真实场景：
- 节点已从集群中 物理下线（比如机器报废），但其他节点仍缓存着它的旧信息（如
CLUSTER NODES里还显示fail?或noaddr） - 你正在搭建测试集群，想快速清空单个节点的集群状态，且确认该节点 没持有任何槽位（
CLUSTER SLOTS返回空） - 节点因网络分区被误判为
fail，手动修复后需清除本地故障标记，但必须先确保它已重新握手成功
常见错误现象：CLUSTER NODES 显示某节点状态为 fail? 却无法踢出；或执行 CLUSTER ADDSLOTS 报 ERR Slot XXX is already busy，实际查发现是旧节点残留槽映射。
CLUSTER RESET 的两个模式和关键区别
它接受一个可选参数，行为完全不同：
-
CLUSTER RESET SOFT（默认）：只清空本地记录的其他节点信息（nodes.conf中的节点列表）、故障标记、槽分配快照，但保留本节点的node_id和已分配的槽位信息 -
CLUSTER RESET HARD：除上述外，还会重置本节点的node_id（生成新 ID）、清空所有已知槽位映射（即使它当前是主节点）、删除所有MOVED重定向缓存
性能影响：HARD 模式会触发一次全集群视角刷新，其他节点收到 UPDATE 消息后需重新同步元数据，短暂增加 gossip 流量；SOFT 几乎无感知。兼容性上，Redis 3.0+ 均支持，但 6.0+ 对 HARD 后的自动重加入更谨慎。
执行前必须检查的三件事
跳过任意一项都可能让集群进入半瘫痪状态：
- 确认该节点当前 不持有任何槽位：执行
CLUSTER SLOTS，返回结果为空数组；若非空，先用CLUSTER DELSLOTS或redis-cli --cluster reshard迁走 - 确认该节点已与集群断开连接：在其他节点执行
CLUSTER NODES，找不到它的id；如果还存在，先用CLUSTER FORGET <node-id></node-id>在其他节点上移除它 - 确认配置文件未硬编码集群参数：检查
redis.conf中是否有cluster-announce-ip、cluster-announce-port等，这些不会被RESET清除，改错会导致重启后自动重入旧集群
典型错误操作：对正在服务的主节点直接跑 CLUSTER RESET HARD，结果它带着新 node_id 重新握手，其他节点认为这是个全新节点，但槽位映射已丢失，整个集群卡在 fail 状态。
重置后真正要做的不是“恢复”，而是“重新加入”
CLUSTER RESET 不等于“初始化完成”。它只是擦掉了本地记忆，接下来必须显式操作才能回归集群：
- 如果是测试环境且想彻底重建：重启 Redis 实例（确保
cluster-enabled yes），再用redis-cli --cluster add-node <port><port></port></port>加入 - 如果节点只是临时失联想复位状态：不用重启，直接执行
CLUSTER MEET <any-other-node-ip><port></port></any-other-node-ip>重新握手，然后等 gossip 同步完成 - 注意
nodes.conf文件权限：重置后该文件会被重写，确保 Redis 进程有写权限，否则下次启动会静默失败
最容易被忽略的点：重置后的节点默认不自动尝试重连，它就停在“孤立”状态，等着你手动 MEET 或外部工具介入。没人敲命令，它就一直安静地当个单机实例。
