集群故障转移

CLUSTER FAILOVER [FORCE | TAKEOVER]

从以下位置开始可用：

3.0.0

时间复杂度：

O（1）

ACL 类别：

@admin, @slow, @dangerous,

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

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

1. 副本通知主服务器停止处理来自客户端的查询。
2. 主服务器使用当前复制偏移量回复副本。
3. 副本等待复制偏移量在其一侧匹配，以确保它在继续之前处理了来自主服务器的所有数据。
4. 副本启动故障转移，从大多数 master 获取新的 configuration epoch，并广播新配置。
5. 旧 master 收到配置更新：解除阻止其客户端并开始回复重定向消息，以便它们继续与新 master 聊天。

这样，客户端就会从旧主服务器移动到新主服务器 原子地，并且仅当副本变成新的 master 已处理来自旧主服务器的所有复制流。

FORCE 选项：Master 宕机时手动故障转移

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

如果给出了 FORCE 选项，则副本不执行任何握手 使用主节点，则可能无法访问，而只是启动 尽快从第 4 点开始进行故障转移。当我们想要启动时，这很有用 当 Master 不再可访问时进行手动故障转移。

但是，使用 FORCE，我们仍然需要大多数 master 可用 为了授权故障转移并生成新的配置纪元 对于将要成为 master 的副本。

TAKEOVER 选项：在没有集群共识的情况下手动故障转移

在某些情况下，这还不够，我们希望副本进行故障转移 未与集群的其余部分达成任何协议。真实用例 因为这是为了将不同数据中心的副本大规模提升为主服务器 为了在所有主服务器都关闭时执行数据中心切换 或分区。

TAKEOVER 选项暗示了 FORCE 所暗示的一切，但也暗示了 不使用任何集群授权进行故障转移。接收CLUSTER FAILOVER TAKEOVER将：

1. 生成新的configEpoch单方面，只需获取当前可用的最大 epoch 并在其本地配置 epoch 尚未最大时递增它。
2. 为其自身分配其 master 的所有哈希槽，并将新配置传播到可尽快访问的每个节点，并最终传播到其他每个节点。

请注意，TAKEOVER 违反了 Redis Cluster 的 last-failover-wins 原则，因为副本生成的配置 epoch 在以下几个方面违反了配置epoch的正常生成：

1. 不能保证它实际上是更高的配置 epoch，因为，例如，我们可以在少数中使用 TAKEOVER 选项，也不会执行任何消息交换来生成新的配置 epoch。
2. 如果我们生成的配置 epoch 恰好与另一个实例发生冲突，则最终我们的配置 epoch 或具有相同 epoch 的另一个实例的配置 epoch 将使用配置 epoch 冲突解决算法移开。

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

实现详细信息和说明

• CLUSTER FAILOVER，除非指定了 TAKEOVER 选项，否则不会同步执行故障转移。 它仅计划手动故障转移，绕过故障检测阶段。
• 一OKreply 不能保证故障转移会成功。
• 只有当集群中的大多数 master 都知道 replica 时，才能将 replica 提升为 master。 如果副本是刚刚添加到集群中的新节点（例如，在升级后），则集群中的所有 master 可能还不知道它。 要检查 master 是否知道新的副本，您可以发送CLUSTER NODES或CLUSTER REPLICAS并检查它是否显示为副本，然后再发送CLUSTER FAILOVER复制到副本。
• 要检查故障转移是否确实发生，您可以使用ROLE,INFO REPLICATION（表示成功故障转移后的 “role：master”），或CLUSTER NODES验证集群的状态在发送命令后的某个时间是否已更改。
• 要检查故障转移是否失败，请检查副本的日志中是否有“手动故障转移超时”，如果副本在几秒钟后放弃，则会记录该日志。

RESP2/RESP3 回复