Previous article: Raft of log replication algorithm

Raft membership of the algorithm change

Sometimes you may encounter on the number of members required to operate the cluster updates, simpler approach will update operations are divided into two stages, all using the old cluster configuration file in the first stage C_old members are all off, it will not be able to process client requests. Then start the cluster members to use the new profile in the second stage. An obvious disadvantage is that the number of members updated when there is not a time to client requests to be processed.
Raft use a new scheme for the members to be updated. Between the two-stage configuration update adds a transition phase, known as the Joint consensus. The introduction of joint realization stage, making changes in cluster membership at the same time, without shutting down the cluster members, which can be processed to client requests in the process of updating the number of members.
It has the following properties in the joint realization stage:

Log entries are copied to all servers in two configurations.
Any server from either configuration can act as a leader.
Elections and submit logs from most people need to accept the old and new configurations, respectively.

Joint agreement allows a single server in the cluster at different times from the old configuration to convert the new configuration, so as not to affect safety. And we can continue to service clients throughout the configuration updates.

1 configuration update process

1.1 Ideally

To add a new member to the cluster, for example, under normal circumstances, assuming that the process does not involve other new request sent by the client:
assuming that the old configuration file is called C_o , a new configuration file called C_n , said the old cluster as C_old , the newly added members called C_new .

When the cluster C_old during normal operation (currently using the old configuration files C_o ), receiving a request for adding new members from the client.
- LeaderDirectly receiving the process, Followerreceiving is redirected to Leader.
LeaderCreate a new log file is used to update the configuration of C_o_n (the log configuration file represents C_old and C_new coexistence members), the configuration file is copied to the majority of the cluster server follows the normal process (including C_old, C_new )
- Including new members C_new , servers always use the latest configuration of its logs, regardless of whether the entry is submitted , Leaderwill be used C_o_n rules to determine when to commit C_o_n log entry.
- That only holds local C_o member configuration log files are still using the old configuration files. Upon receiving the C_o_n after whether or not the configuration file has been applied to a copying machine state, will use C_o_n profile as the profile server.
When the new log file C_o_n after successfully submitted in the cluster, enter a joint consensus stage.
After entering the joint realization stage, Leadercreate a new configuration updates for the new profile C_n , and send the logs to the most C_new server (literature says so, so far do not understand why not all servers) .

When configuring the log file C_n After a successful submission, it means that members of the update process is complete, the new cluster configuration file C_n continue to operate according to the normal procedures.

If you do not consider the case of a new request sent by the client and the server crash, the update can be configured regarded as a common log file, send accordance with normal procedures, to submit applications after the update is complete configuration success. The only difference is that after the common log file will need to submit the application to copy state machine, and the configuration file log is when the server receives, whether or not has been submitted to the received configuration information will take effect.

1.2 Joint realization stage

Joint realization stage: refers C_o_n configuration log files successfully submitted to most servers in the cluster, and C_n configuration log file has not been submitted to the time period between the cluster most servers.
At this stage, any action (electoral or other logging request) for C_old and C_new members who can not make decisions alone. The need C_old and C_new most of the server to make decisions at the same time. (As the author condition is successfully copied to log most of the server, so when C_o_n After the log file is submitted, it is possible there are still part of the server does not receive C_o_n log file is still in C_old stage, C_new members, too)

2 `Leader`crashes

Respectively, said that from the point several times about the Leadermeasures crashes occur at various stages:

C_o_n configuration before the uncommitted log files.
C_o_n After you configure the log file is filed and C_n configurable time period between the front uncommitted log files (joint realization stage) of
C_n After the log file configuration is submitted.

2.1 C_o_n Before configuring uncommitted log files

From the initial cluster up to normal operating state C_o_n configuration log files are submitted during this time, if LeaderBen collapse, then the elected Leadermembers may be using C_o members, may also be received C_o_n members of the configuration log file. Because C_o_n configuration log file has not yet been submitted, so C_oldmembers can make decisions alone. The C_newmembers can not make decisions alone.

2.2 Joint realization stage

C_o_n After you configure the log file is filed and C_n configuration log files are not submitted before the time period between the due C_o_n only when copied to configure log file C_old and C_new was only submitted after most members of both, so when submitting C_o_n configure log after the file, use C_o_n configuration log file members of the majority of all members of the server, so if you Leadercrash, you can only use from C_o_n select members of the configuration log file Leader. This time for C_old and C_new members who can not make decisions alone, and therefore can not use C_o and C_n selected members of the Leader.

2.3 C_n After you configure the log file submitted

When the log submission, in fact, has finished updating membership in the network. So Leaderthe election to the same phase and normal operation.

3 Problems

In the update phase of membership, there are three main issues:

The newly added members may not store any previous log entries, if they are added to the cluster, the log entries Leaderbefore the completion of the synchronization, is unable to submit a new log entries.
LeaderIt may not be part of the new configuration in the cluster.
Updated assumptions membership is the cluster members deleted, the deleted node may disrupt cluster.

3.1 a problem

To solve this problem, Raft approach is to introduce a new state, allowing new members to have the identity of a non-decision-making power (elections and participating in log submitted) to join the cluster, so the election Leaderor whether statistics logs have been distributed to large when some members, the member will not be considered. Log stores up to the member states to catch up with the other members of the cluster, and then give the members of the decision-making power.

3.2 Question two

The reason : the cause of the problems is that the number may be newly added to the cluster of new members is much older than the number of clusters ( personal understanding, if there is an error welcome that ). Because when it comes before the C_n configuration log files need to be sent to C_new most members, but Leaderdoes not belong to C_newone of the. So send C_n time configuration log file, Leaderit will be on C_new members of the management.
Solution : When C_n the log successful completion of the submission, which Leaderautomatically converted to identity Follower, and then from C_new elected a new member of Leader.

3.3 Question three

The reason : If the deleted server does not close, then they will not receive heartbeat messages and log information, so as to continuously timeout occurs, leading to increasing term (a term greater than all members of the cluster), and then continue to send to the cluster voting request message. The cluster Leaderbecomes Follower, the cluster will continue to start new elections. Thereby disrupting the normal operation of the cluster.
Solution : Raft the introduction of a minimum timeout election, meaning that if a cluster exists Leaderwhen, and after receiving a heartbeat message received request to vote in the election of a minimum timeout period, then the vote will ignore the message.

Next article: Raft of log compression algorithm