Raft (algorithm): Difference between revisions

Revision as of 15:36, 11 September 2017

Revision as of 13:39, 19 September 2017

Line 21:

The leader is responsible for the log replication. It accepts client requests. Each client request consist in a command to be executed by the replicated state machines in the cluster. After being appended to the leader's log as a new entry, each of the requests is forwarded to the followers in AppendEntries messages. In case of unavailability of the followers, the leader retries AppendEntries messages indefinitely, until the log entry is enventually stored by all of the followers.

Once the leader receives confirmation from the majority of its followers that the entry ashas been replicated, the leader apply the entry to its local state machine, and the request is considered ''committed''.<ref name="paper" /><ref name="secretlives" /> This event also commits all previous entries in the leader's log. Once a follower learns that a log entry is committed, it applies the entry to its local state machine. It provides consistency for the logs between all the servers through the cluster, insuring that the safety rule of Log Matching is respected.

In the case of leader crash, the logs can be left inconsistent, with some logs from the old leader not being fully replicated through the cluster. The new leader will then handle inconsistency by forcing the followers to duplicate its own log. To do so, for each of its followers, the leader will compare its log with the log from the follower, find the last entry where they agree, then delete all the entries coming after this critical entry in the follower log and replace it with its own log entries. This mechanism will restore log consistency in a cluster subject to failures.