5.替换主节点
当从节点收集到足够的选票之后，触发替换主节点操作：
1）当前从节点取消复制变为主节点。
2）执行 clusterDelSlot 操作撤销故障主节点负责的槽，并执行 clusterAddSlot 把这些槽委派给自己。
3）向集群广播自己的 pong 消息，通知集群内所有的节点当前从节点变为主节点并接管了故障主节点的槽信息。
Redis.6.3 故障转移时间
在介绍完故障发现和恢复的流程后，这时我们可以估算出故障转移时间：
1）主观下线（pfail）识别时间=cluster-node-timeout。
2）主观下线状态消息传播时间<=cluster-node-timeout/2。消息通信机制对超过 cluster-node-timeout/2 未通信节点会发起 ping 消息，消息体在选择包含哪些节点时会优先选取下线状态节点，所以通常这段时间内能够收集到半数以上主节点的 pfail 报告从而完成故障发现。
3）从节点转移时间<=1000 毫秒。由于存在延迟发起选举机制，偏移量最大的从节点会最多延迟 1 秒发起选举。通常第一次选举就会成功，所以从节点执行转移时间在 1 秒以内。
根据以上分析可以预估出故障转移时间，如下：
failover-time(毫秒) ≤ cluster-node-timeout cluster-node-timeout/2 1000因此，故障转移时间跟 cluster-node-timeout 参数息息相关，默认 15 秒。配置时可以根据业务容忍度做出适当调整，但不是越小越好，下一节的带宽消耗部分会进一步说明。
10.6.4 故障转移演练
到目前为止介绍了故障转移的主要细节，下面通过之前搭建的集群模拟主节点
故障场景，对故障转移行为进行分析。使用 kill-9 强制关闭主节点 6385 进程，如图所示。
确认集群状态：
127.0.0.1:6379> cluster nodes 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756
127.0.0.1:6385 master - 0 1471877563600 16 connected 0-1365 5462-6826 10923-
12287 15018-16383 40622f9e7adc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382
slave cfb28ef1deee4e0fa78da
……
强制关闭 6385 进程：
# ps -ef | grep redis-server | grep 6385
501 1362 1 0 10:50 0:11.65 redis-server *:6385 [cluster]
# kill -9 1362
日志分析如下：
·从节点 6386 与主节点 6385 复制中断，日志如下：
==> redis-6386.log <==
# Connection with master lost.
* Caching the disconnected master state.
* Connecting to MASTER 127.0.0.1:6385
* MASTER <-> SLAVE sync started
# Error condition on socket for SYNC: Connection refused
·6379 和 6380 两个主节点都标记 6385 为主观下线，超过半数因此标记为客观下线状态，打印如下日志：
==> redis-6380.log <==
* Marking node 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756 as failing (quorum
reached).
==> redis-6379.log <==
* Marking node 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756 as failing (quorum
reached).
·从节点识别正在复制的主节点进入客观下线后准备选举时间，日志打印了选举延迟 964 毫秒之后执行，并打印当前从节点复制偏移量。
==> redis-6386.log <==
# Start of election delayed for 964 milliseconds (rank #0, offset 1822).
·延迟选举时间到达后，从节点更新配置纪元并发起故障选举。
==> redis-6386.log <==
1364:S 22 Aug 23:12:25.064 # Starting a failover election for epoch 17.
·6379 和 6380 主节点为从节点 6386 投票，日志如下：
==> redis-6380.log <==
# Failover auth granted to 475528b1bcf8e74d227104a6cf1bf70f00c24aae for epoch 17
==> redis-6379.log <==
# Failover auth granted to 475528b1bcf8e74d227104a6cf1bf70f00c24aae for epoch 17
·从节点获取 2 个主节点投票之后，超过半数执行替换主节点操作，从而完成故障转移：
==> redis-6386.log <==
# Failover election won: I'm the new master.
# configEpoch set to 17 after successful failover
成功完成故障转移之后，我们对已经出现故障节点 6385 进行恢复，观察节点状态是否正确：
1） 重新启动故障节点 6385。
2） 6385 节点启动后发现自己负责的槽指派给另一个节点，则以现有集群配置
为准，变为新主节点 6386 的从节点，关键日志如下：
# I have keys for slot 4096, but the slot is assigned to another node. Setting it
to
importing state.
# Configuration change detected. Reconfiguring myself as a replica of
475528b1bcf8e74d227104a6cf1bf70f00c24aae
3) 集群内其他节点接收到 6385 发来的 ping 消息，清空客观下线状态：
==> redis-6379.log <==
* Clear FAIL state for node 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756: master
without
slots is reachable again.
==> redis-6380.log <==
* Clear FAIL state for node 1a205dd8b2819a00dd1e8b6be40a8e2abe77b756: master
without
slots is reachable again.
……
4）6385 节点变为从节点，对主节点 6386 发起复制流程：
==> redis-6385.log <==
* MASTER <-> SLAVE sync: Flushing old data
* MASTER <-> SLAVE sync: Loading DB in memory
* MASTER <-> SLAVE sync: Finished with success
5）最终集群状态如图所示。
