cluster failover是Redis集群中唯一能绕过选举逻辑、手动将Slave提升为Master的命令，适用于原Master短暂宕机后以Slave身份重连、需流量调度至特定Slave、或集群节点不足导致自动故障转移失效等场景。
Redis集群中Master挂了，不能靠等自动恢复——尤其当原Master重启后变成Slave、你又想让它重新当Master时，cluster failover 是唯一能绕过选举逻辑、直接干预角色的命令。
什么时候必须用 cluster failover 而不是等自动故障转移
自动故障转移只在原Master被判定为“永久下线”且多数节点同意后才触发，但现实中常见以下情况它不生效：
- 原Master只是短暂宕机（比如进程被误杀），几秒后自己拉起来了，集群仍视其为有效节点，不会触发切换
- 原Master恢复后连回集群，但只能以Slave身份加入，因为集群已把槽位和主角色分配给了别的节点
- 你想把流量切到某台性能更好/位置更优的Slave上，但该Slave还没被选为新Master（比如投票未过半）
- 集群节点数不足（少于3个Master），导致客观下线（ODOWN）无法达成，自动流程卡死
cluster failover 的三种模式怎么选
这个命令必须在目标Slave节点上执行，行为差异极大，选错会导致数据丢失或脑裂：
-
cluster failover（无参数）：默认模式。Slave先与当前Master同步offset，确认数据一致后才发起切换。安全但要求Master在线且网络通畅 -
cluster failover force：跳过offset校验，不跟Master通信，直接向其他Master广播切换请求。适用于Master已失联但尚未被集群标记为ODOWN的场景 -
cluster failover takeover：完全不协商，不发广播，本地直接把自己设为Master，并修改配置纪元（config epoch）。仅用于极端情况——比如整个集群只剩这一个存活节点，且你明确接受数据可能陈旧
⚠️ 注意：takeover 模式下，该节点会拒绝所有来自其它节点的CLUSTER MEET或REPLICATE请求，直到你手动执行CLUSTER RESET或重启。
执行前必须验证的三件事
直接连上目标Slave执行命令前，先确认：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 该节点确实是Slave角色：
redis-cli -p 6380 INFO replication | grep role输出应为role:slave - 它有明确的Master：
redis-cli -p 6380 INFO replication | grep master_host不为空，且master_link_status:up - 它的复制偏移量（
slave_repl_offset）接近Master的master_repl_offset——差值超过几万说明同步严重滞后，force或takeover都可能丢数据
一次安全的手动提升实操（以6380节点为例）
假设你想让6380从Slave升为Master，且当前Master（6379）已不可达但尚未被集群踢出：
redis-cli -c -p 6380 127.0.0.1:6380> cluster failover force
执行后立刻检查：
- 日志里应出现类似
Failover triggered for node xxxxx, taking over as master -
redis-cli -p 6380 cluster nodes中该节点flag应含master，且不再显示slave字样 - 原Master（6379）若还活着，会收到集群配置更新，自动降级为Slave并开始同步6380
如果6379已彻底离线，而你又希望6380接管全部槽位，还需紧接着执行：redis-cli -p 6380 cluster addslots {0..16383} ——但这一步只有在确认无其它Master存活时才可操作，否则会破坏集群一致性。
真正容易被忽略的是：执行cluster failover后，客户端连接字符串里的startup-nodes或initial-contact-points未必自动感知新Master，尤其是使用老版本Jedis/Lettuce驱动时，可能缓存着旧拓扑信息，得清掉本地路由表或重启应用实例。
