CLUSTER FAILOVER

CLUSTER FAILOVER [FORCE | TAKEOVER]

可用版本

Redis 开源版本 3.0.0

时间复杂度

O(1)

ACL 分类

@admin， @slow， @dangerous，

此命令只能发送到 Redis Cluster 的副本节点，用于强制副本节点启动其主节点的手动故障转移。

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

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

通过这种方式，客户端从旧主节点原子地转移到新主节点，并且只有在将要成为新主节点的副本节点处理完旧主节点的所有复制流之后才会进行转移。

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

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

如果指定了 **FORCE** 选项，副本节点不会与主节点（可能不可达）进行握手，而是从第 4 点开始尽快启动故障转移。当主节点不再可达时，此选项在启动手动故障转移时非常有用。

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

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

在某些情况下，这仍然不够，我们希望副本节点能够在未经集群其余节点任何同意的情况下进行故障转移。一个实际用例是在所有主节点都宕机或被隔离时，为了进行数据中心切换，在不同数据中心批量将副本节点提升为主节点。

**TAKEOVER** 选项包含 **FORCE** 选项的所有含义，此外还无需任何集群授权即可进行故障转移。接收到 `CLUSTER FAILOVER TAKEOVER` 命令的副本节点将改为：

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

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

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 回复