CLUSTER FAILOVER

此命令只能发送到 Valkey 集群的副本节点，它强制副本节点启动其主实例的手动故障转移。

手动故障转移是一种特殊的故障转移，通常在没有实际故障发生，但我们希望安全地将当前主节点与其某个副本节点（即我们发送命令的节点）进行交换，且不留下任何数据丢失窗口时执行。它的工作方式如下：

1. 副本节点告知主节点停止处理来自客户端的查询。
2. 主节点回复副本节点当前的复制偏移量。
3. 副本节点等待自身的复制偏移量与主节点匹配，以确保在继续之前已处理了来自主节点的所有数据。
4. 副本节点启动故障转移，从大多数主节点获取新的配置纪元，并广播新配置。
5. 旧主节点收到配置更新：解除客户端阻塞，并开始回复重定向消息，以便客户端继续与新主节点通信。

这样，客户端在旧主节点的所有复制流已被转换为新主节点的副本节点处理完毕后，才原子性地从旧主节点迁移到新主节点。

如果副本节点未能及时跟上或无法获得接管的投票，主节点将有一个内置的超时机制来恢复查询处理。默认的故障转移超时时间是 5000 毫秒。可以通过 cluster-manual-failover-timeout 配置参数（在 Valkey 8.1 中添加）来配置此超时时间，并决定在最坏情况下主节点将暂停多久。

FORCE 选项：主节点宕机时的手动故障转移

命令行为可以通过两个选项进行修改：FORCE 和 TAKEOVER。

如果指定了 FORCE 选项，副本节点不会与主节点（可能无法访问）进行任何握手，而是从第 4 点开始尽快启动故障转移。当主节点不再可达时，这对于启动手动故障转移很有用。

然而，使用 FORCE 选项时，我们仍然需要大多数主节点可用，以便授权故障转移并为将要成为主节点的副本节点生成新的配置纪元。

TAKEOVER 选项：无需集群共识的手动故障转移

有些情况下，这还不够，我们希望副本节点在不与集群其余部分达成任何协议的情况下进行故障转移。一个实际的应用场景是，当所有主节点都宕机或被分区隔离时，为了执行数据中心切换，将不同数据中心的大量副本节点提升为新的主节点。

TAKEOVER 选项包含 FORCE 选项所暗示的一切，但它在故障转移时也不使用任何集群授权。接收 CLUSTER FAILOVER TAKEOVER 命令的副本节点将转而：

1. 单方面生成一个新的 configEpoch，仅获取当前可用的最大纪元并递增它，如果其本地配置纪元尚未是最大的。
2. 将其主节点的所有哈希槽分配给自己，并尽快将新配置传播到每个可达节点，并最终传播到所有其他节点。

请注意，TAKEOVER 违反了 Valkey 集群的“最后故障转移者胜”原则，因为副本节点生成的配置纪元在多个方面违反了配置纪元的正常生成方式：

1. 无法保证它实际上是更高的配置纪元，因为例如，我们可以在少数派中使用 TAKEOVER 选项，并且不会执行任何消息交换来生成新的配置纪元。
2. 如果我们生成的配置纪元与另一个实例发生冲突，最终我们的配置纪元，或与我们相同纪元的另一个实例的纪元，将通过使用配置纪元冲突解决算法而被移开。

因此，应谨慎使用 TAKEOVER 选项。

实现细节和注意事项

• CLUSTER FAILOVER 命令，除非指定了 TAKEOVER 选项，否则不会同步执行故障转移。它只会安排一次手动故障转移，绕过故障检测阶段。
• 收到 OK 回复并不保证故障转移一定会成功。
• 副本节点只有在集群中大多数主节点都将其识别为副本节点时，才能被提升为主节点。如果副本节点是刚刚添加到集群的新节点（例如在升级后），它可能尚未被集群中的所有主节点识别。在向副本节点发送 CLUSTER FAILOVER 命令之前，您可以通过向每个主节点发送 CLUSTER NODES 或 CLUSTER REPLICAS 命令来检查主节点是否已识别该新副本节点。
• 要检查故障转移是否已实际发生，您可以使用 ROLE、INFO REPLICATION（在成功故障转移后会显示“role:master”）或 CLUSTER NODES 来验证集群的状态在命令发送后某个时间点是否已更改。
• 要检查故障转移是否失败，请查看副本节点的日志中是否有“Manual failover timed out”信息，如果副本节点在几秒后放弃，就会记录此信息。

RESP2/RESP3 回复

简单字符串回复：如果命令被接受并将尝试手动故障转移，则回复 OK。如果操作无法执行，例如客户端连接到一个已是主节点的节点，则回复错误。