cluster failover

CLUSTER

CLUSTER FAILOVER [FORCE|TAKEOVER]

自3.0.0起可用。

时间复杂度： O（1）

该命令只能发送到 Redis 集群从节点，强制从节点启动其主节点的手动故障转移。

手动故障转移是一种特殊的故障转移，通常在没有实际故障时执行，但我们希望以安全的方式将当前主控与其中一个从属（这是我们发送命令的节点）交换，没有任何数据丢失的窗口。它的工作原理如下：

1. 奴隶告诉主人停止处理来自客户的查询。

2. 主站使用当前复制偏移量答复从站。

3. 从服务器等待复制偏移量与其匹配，以确保它在继续处理之前处理来自主服务器的所有数据。

4. 从站启动故障转移，从大多数主站获得新的配置时期，并广播新配置。

5. 旧的主服务器接收配置更新：取消阻止其客户端并开始使用重定向消息进行回复，以便他们继续与新主服务器聊天。

这样，客户端就会以原子方式从旧主控制器移动到新主控制器，并且只有当变成新主控制器的从控制器才处理来自旧主控制器的所有复制流时。

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

如果给出 FORCE 选项，则从站不会与主站进行任何握手，但可能无法到达，而是从第4点开始尽快启动故障切换。这对于我们希望在主站点启动手动故障切换时非常有用不再可达。

但是，使用 FORCE，我们仍然需要大多数主设备可用，以授权故障切换并为将成为主设备的从设备生成新的配置时期。

有些情况下，这是不够的，我们希望奴隶故障转移与群集的其他部分没有任何协议。一个真实世界的用例就是在不同的数据中心大量推销奴隶，以便掌握数据中心交换机，而所有主数据中心都被关闭或分区。

TAKEOVER 选项意味着一切 FORCE 意味着，但也不会为了使用故障转移群集的任何授权。取而代之的CLUSTER FAILOVER TAKEOVER是奴隶收到：

1. 生成一个新的configEpoch单方面，只是采取当前最大的纪元可用，并增加它，如果它的本地配置时代还不是最大的。

2. 为其主节点的所有散列槽分配自己，并将新配置传播到每个可以尽快到达的节点，并最终传播到每个其他节点。

请注意，TAKEOVER 违反了 Redis 集群的最后一次故障切换赢得原则，因为从属设备生成的配置时期违反了以下几种方式正常生成配置时期：

1. 不能保证它实际上是更高的配置时期，因为例如我们可以在少数中使用 TAKEOVER 选项，也不会执行任何消息交换来生成新的配置时期。

2. 如果我们生成一个碰巧与另一个实例发生冲突的配置时期，那么最终我们的配置时期或另一个具有相同时期的实例将会使用配置时期冲突解决算法移走。

因此，应小心使用 TAKEOVER 选项。

CLUSTER FAILOVER，除非指定了 TAKEOVER 选项，否则不会同步执行故障转移，它仅调度手动故障转移，绕过故障检测阶段，因此为了检查是否真的发生了故障转移，应该使用 CLUSTER NODES 或其他方法验证在发送命令一段时间后群集的状态是否发生更改。

简单字符串回复：OK如果该命令被接受并且将尝试手动故障转移。如果操作无法执行，例如，如果我们正在与已经是主节点的节点交谈，则会出错。