20-故障恢复

8.3.5 故障恢复

在一个集群中，每个节点都会定期向其他节点发送 PING 命令，并通过有没有收到回复来判断目标节点是否已经下线了。具体来说，集群中的每个节点每隔1秒钟就会随机选择5个节点，然后选择其中最久没有响应的节点发送 PING 命令。

如果一定时间内目标节点没有响应回复，则发起 PING 命令的节点会认为目标节点疑似下线（ PFAIL ）。疑似下线可以与哨兵的主观下线类比，两者都表示某一节点从自身的角度认为目标节点是下线的状态。与哨兵的模式类似，如果要使在整个集群中的所有节点都认为某一节点已经下线，需要一定数量的节点都认为该节点疑似下线才可以，这一过程具体为：

（1）一旦节点A认为节点B是疑似下线状态，就会在集群中传播该消息，所有其他节点收到消息后都会记录下这一信息；

（2）当集群中的某一节点C收集到半数以上的节点认为B是疑似下线的状态时，就会将B标记为下线（ FAIL ），并且向集群中的其他节点传播该消息，从而使得B在整个集群中下线。

在集群中，当一个主数据库下线时，就会出现一部分插槽无法写入的问题。这时如果该主数据库拥有至少一个从数据库，集群就进行故障恢复操作来将其中一个从数据库转变成主数据库来保证集群的完整。选择哪个从数据库来作为主数据库的过程与在哨兵中选择领头哨兵的过程一样，都是基于Raft算法，过程如下。

（1）发现其复制的主数据库下线的从数据库（下面称作A）向每个集群中的节点发送请求，要求对方选自己成为主数据库。

（2）如果收到请求的节点没有选过其他人，则会同意将A设置成主数据库。

（3）如果A发现有超过集群中节点总数一半的节点同意选自己成为主数据库，则A则成功成为主数据库。

（4）当有多个从数据库节点同时参选主数据库，则会出现没有任何节点当选的可能。此时每个参选节点将等待一个随机时间重新发起参选请求，进行下一轮选举，直到选举成功。

当某个从数据库当选为主数据库后，会通过命令 SLAVEOF ON ONE 将自己转换成主数据库，并将旧的主数据库的插槽转换给自己负责。

如果一个至少负责一个插槽的主数据库下线且没有相应的从数据库可以进行故障恢复，则整个集群默认会进入下线状态无法继续工作。如果想在这种情况下使集群仍能正常工作，可以修改配置 cluster-require-full-coverage``为``no （默认为 yes ）：

cluster-require-full-coverage no