CLUSTER FAILOVER 能在从库执行，但要求主节点在线健康；否则报错 ERR Master is down or failed。FORCE 跳过等待投票，TAKEOVER 单方面晋升，仅用于主永久失联且接受脑裂风险的极端场景。
CLUSTER FAILOVER 能不能在从库上直接执行
能，但必须满足前提：该从库的主节点（master）当前在线且健康。否则命令会直接报错 ERR Master is down or failed。Redis 集群的故障转移不是“谁想升就升”，而是“主挂了才轮到你接班”。CLUSTER FAILOVER 本质是模拟一次主节点宕机后的自动选举流程，但它要求主节点还在心跳中——只是你主动按下了“开始选举”按钮。
常见错误现象：CLUSTER FAILOVER 返回 ERR No master to failover 或 ERR Master is down，其实不是命令写错了，而是你连到了一个已经失联主节点的从库，或者主节点正在网络分区中但尚未被集群标记为 fail 状态。
- 执行前先确认主节点状态：
CLUSTER NODES查看目标从库那一行，其 master ID 对应的节点是否为master角色且没有fail标记 - 必须在目标从库节点上执行，不能在其他节点上远程触发
- 不支持带参数的强制模式（比如
FORCE或TAKEOVER）——除非你用的是 Redis 5.0+ 且主节点已不可达（见下一条）
FORCE 和 TAKEOVER 参数的区别和适用场景
CLUSTER FAILOVER FORCE 和 CLUSTER FAILOVER TAKEOVER 是两个关键变体，它们绕过了对主节点在线的检查，但用途截然不同。
FORCE 仍走标准选举流程，只是跳过“等待多数节点同意”的等待期，适用于主节点卡顿、响应慢但还没被判定为 fail 的情况；而 TAKEOVER 是彻底跳过集群共识，由该从库单方面宣布自己晋升为主，仅用于极端场景：主节点永久失联、集群无法达成多数派、且你愿意承担脑裂风险。
-
FORCE：主节点还在，但疑似僵死；执行后仍需其他主节点投票，失败率低 -
TAKEOVER：主节点确认消失，且集群多数节点不可达（比如只剩 2 个节点在线）；执行后不会广播配置纪元（config epoch）变更，其他节点可能拒绝同步 - Redis 4.0 及更早版本不支持这两个参数，会直接报错
ERR Unknown subcommand
执行后为什么新主没被其他节点承认
常见表现是：你在从库上成功执行了 CLUSTER FAILOVER，CLUSTER NODES 显示它变成了 master，但其他节点日志里持续打印 Ignoring the gossip for ... because of an unknown node，或客户端仍往旧主地址发请求。
根本原因在于配置纪元（config epoch）未正确传播。Redis 集群靠递增的 config epoch 来标识拓扑变更，只有当多数主节点接受并更新了这个新 epoch，整个集群才算完成切换。手动触发时若网络延迟高、部分节点掉线、或执行节点本身配置落后，就容易卡在这一步。
- 执行后立刻在所有主节点上运行
CLUSTER NODES，确认新主的 config epoch 是否高于旧主 - 如果新主 epoch 没变，说明
FAILOVER实际未生效，可能是被其他节点拒绝或超时 - 不要依赖单次
CLUSTER NODES输出；等 10–20 秒再查，观察 epoch 是否逐步收敛
脚本化触发时最容易漏掉的检查项
自动化运维脚本里常把 CLUSTER FAILOVER 当成原子操作，但实际它有隐含依赖链。最常被跳过的，是“确认该从库数据最新”这一步。
Redis 不保证从库复制偏移量（slave_repl_offset）实时等于主库（master_repl_offset），尤其在主从延迟高、网络抖动时。一旦用一个明显落后的从库执行 TAKEOVER，就会丢失写入。
- 执行前务必比对：
INFO replication中的master_repl_offset和目标从库的slave_repl_offset，差值应 - 避免在
CLUSTER NODES显示noaddr或fail?状态的节点上执行 - 不要在
redis-cli -c（集群模式）下执行；必须直连目标从库 IP:PORT，否则命令会被重定向到随机节点，大概率失败
真正麻烦的从来不是命令敲不对，而是你以为它成功了，其实集群还在静默分裂。多看一眼 CLUSTER NODES 输出里的 epoch 和 flags 字段，比重试三遍更有用。
