Raft membership change

以你之姓@ 2022-06-08 01:07 217阅读 0赞

**Raft membership change**

要保证成员变更过程中的safety，就要保证在任何时候，都不会出现双主。

如果一次成员变更中，将成员组立刻切换为新的成员组，那么就会因为各个成员之间不能同时生效而导致双主，如图。

[![disjoint-majorities][]][disjoint-majorities]

从(S1,S2,S3)变为(S1,S2,S3,S4,S5)的变更中，因为各个成员上变更生效时间不同，可能导致在中间某个时刻，出现两个disjoint majorities，两个多数派能够分别选主并服务客户端，导致一致性无法保证。

为了保证safety，常规的解法是使用两个阶段。例如，在Viewstamped Replication协议里，成员变更先停止旧的成员组，然后启用新的成员组，但是这样导致中间会有停服务的问题。

Raft里采用的两阶段方案是，集群先进入一个称之为Joint Consensus的过渡状态，等过渡状态commit了，再只使用新的成员组。在Joint Consensus中，不管是日志复制（客户端提交的普通日志）还是选主，都要在新旧两个成员组C\_old、C\_new内分别形成多数派。

成员变更命令通过成员变更日志作为载体复制到其他副本。一个副本只要收到了成员变更日志，之后的日志就立刻使用新的成员组开始工作，不管这条成员变更是不是commit了。也就是说，leader要用两个多数派C\_old,new同时满足来commit这条成员变更日志。

因为有Joint Consensus，所以在C\_old,new commit之前，C\_new无法单方面确认任何事情。那么，在C\_old,new commit之前如果leader宕机了呢？这种情况下，C\_old或者C\_old,new可能选出新的leader（取决于新主上是否有C\_old,new这条日志）。同样，C\_new仍然无法单方面确认任何事情。

一旦C\_old,new commit了，那么即使leader宕机，选出来的新leader也一定有C\_old,new这条日志了（选主的约束：Leader拥有全部commit的日志）。此时，leader发起一个成员变更，将状态转为只使用C\_new的状态（这条日志也记为C\_new）。直到C\_new被commit了，C\_old便不再被需要。成员变更的两个阶段就完成了。  
这个过程如图示：

[![joint\_consensus][joint_consensus]][joint_consensus]

成员变更保证safety，要遵循的原则是：在任何时候都不允许C\_old和C\_new同时可以单方面做决定。例如图中上半部分，C\_old和C\_new分别可以单方面做决定的时间段是没有重叠的，中间使用C\_old,new过渡。

[disjoint-majorities]: /images/20220608/414e511954c74cf797763eddfc022ea1.png
[joint_consensus]: /images/20220608/9f5d00f1bfa74b89ac1972c3ad74e971.png