cluster failover需主节点在线健康，否则报错；支持无参（默认）、force（跳过健康检查但需ping响应）、takeover（强制晋升，仅主永久失效时用）；迁移后须在所有节点执行cluster forget清理元数据；停机前需等待cluster nodes显示fail?状态。
关闭前必须确认节点是否为主节点
直接对从节点执行 CLUSTER FAILOVER 会报错：ERR Master down or failed, can't failover。这个命令只在从节点上有效，且要求其主节点在线、健康、未被标记为 fail。如果主节点已宕机或处于 fail 状态，得先用 CLUSTER FAILOVER FORCE 或人工干预恢复主从关系，否则迁移无法启动。
实操建议：
- 用
CLUSTER NODES查看目标节点角色，确认slave标识及对应master_id - 检查主节点状态：若其
flags含fail或连接超时，先修复网络或重启主节点 - 避免在主节点正在执行
CLUSTER SETSLOT ... MIGRATING期间触发 failover，可能引发槽位状态不一致
CLUSTER FAILOVER 的三种模式怎么选
CLUSTER FAILOVER 支持无参、FORCE、TAKEOVER 三种调用方式，行为差异直接影响迁移安全性和集群稳定性。
关键区别：
- 无参（默认）：要求主节点在线、可通信，且当前从节点复制偏移量与主节点差距 ≤ 200 MB（由
cluster-replica-validity-factor控制），否则拒绝切换 -
FORCE：跳过主节点健康检查，但仍需主节点能响应 PING；适用于主节点卡顿但未完全失联的场景 -
TAKEOVER：完全绕过主节点，强制晋升为新主；仅应在主节点永久不可用、且你已确认无数据丢失风险时使用（例如主节点磁盘损坏、无 AOF/RDB 可恢复）
示例：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
CLUSTER FAILOVER FORCE比
CLUSTER FAILOVER 多一次心跳校验跳过，但不会像 TAKEOVER 那样重写配置纪元（config_epoch），更适合临时故障下的平滑接管。
迁移槽位后必须手动触发 CLUSTER FORGET
节点被优雅下线后，其他节点配置中仍保留其 ID 和地址信息，导致 CLUSTER NODES 输出冗余条目，甚至影响后续扩容或故障检测逻辑。Redis 不会自动清理已下线节点的元数据。
操作要点：
- 在**所有剩余节点**上依次执行
CLUSTER FORGET <offline-node-id></offline-node-id>，不能只在某一台上运行 - 执行前确保该节点已彻底断开连接（TCP 连接消失、无
ping往来），否则会被重新发现并加回列表 - 若忘记执行，下次
CLUSTER MEET新节点时可能因旧节点残留导致握手失败或配置冲突
停掉 Redis 进程前要等 CLUSTER NODES 显示“fail?”状态
执行完 CLUSTER FAILOVER 并确认新主节点已接管全部槽位后，原主节点仍可能短暂维持 connected 状态。此时直接 kill 或 systemctl stop 它，会导致其他节点在几秒内持续尝试重连，产生大量 Connection refused 日志，并延迟感知其下线。
正确节奏：
- 观察
CLUSTER NODES输出，等待目标节点状态变为fail?（注意带问号），表示多数节点已共识其失效 - 若长时间卡在
connected或noaddr，检查防火墙、DNS 解析或cluster-node-timeout设置（默认 15s，太小易误判） - 确认无客户端仍在向该节点发请求（如通过
redis-cli -h <old-ip> ping</old-ip>测试）再终止进程
真正麻烦的不是命令怎么敲，而是每个节点的状态判断都依赖集群视角的一致性——差一个心跳，就可能多等 15 秒，或者多一条残留记录。
