CLUSTER FAILOVER

CLUSTER FAILOVER [FORCE | TAKEOVER]

可用版本

3.0.0

时间复杂度

O(1)

ACL 类别

@admin, @slow, @dangerous,

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

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

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

这样，客户端就会原子地从旧主节点转移到新主节点，并且只有在新主节点已处理来自旧主节点的所有复制流时才会进行转移。

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

可以使用两个选项修改命令的行为：FORCE 和 TAKEOVER。

如果给出 FORCE 选项，则从节点不会执行任何与主节点的握手（该主节点可能无法访问），而是立即启动故障转移，从步骤 4 开始。这在希望在主节点不再可达时启动手动故障转移时很有用。

但是，使用 FORCE 仍然需要大多数主节点可用，以便授权故障转移并为即将成为主节点的从节点生成新的配置纪元。

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

在某些情况下，这还不够，我们需要一个从节点在没有与集群其他节点达成一致的情况下进行故障转移。一个实际用例是将不同数据中心的大量从节点提升为主节点，以执行数据中心切换，而所有主节点都已宕机或分区。

TAKEOVER 选项隐含了 FORCE 的所有含义，但它也不使用任何集群授权来执行故障转移。接收 CLUSTER FAILOVER TAKEOVER 的从节点将执行以下操作：

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

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

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

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

实现细节和注意事项

• CLUSTER FAILOVER（除非指定了 TAKEOVER 选项）不会同步执行故障转移。它只会计划手动故障转移，绕过故障检测阶段。
• OK 回复不能保证故障转移会成功。
• 一个从节点只有在其被集群中的大多数主节点识别为从节点时才能被提升为主节点。如果从节点是新添加的节点（例如，在升级后），它可能还没有被集群中的所有主节点识别。要检查主节点是否知道新的从节点，可以在每个主节点上发送 CLUSTER NODES 或 CLUSTER REPLICAS 命令，并检查它是否显示为从节点，然后再向从节点发送 CLUSTER FAILOVER 命令。
• 要检查故障转移是否已成功，您可以使用 ROLE、INFO REPLICATION（在故障转移成功后显示“role:master”）或 CLUSTER NODES 来验证集群状态在命令发送后是否已更改。
• 要检查故障转移是否失败，请检查副本日志中是否存在“Manual failover timed out”，如果副本在几秒钟后放弃，则会记录此日志。

RESP2/RESP3 回复