RAFT

What is the Raft protocol

• RAFT designed as an alternate to paxos.
• Generic way to distribute a state machine among a set of servers and ensure that every server agrees upon the same series of state transition.

Raft works by electing a leader in the cluster. The leader is responsible for accepting client requests and managing the replication of the log to other servers. The data flows only in one direction: from leader to other servers.

Raft decomposes consensus into three sub-problems:

• Leader Election: A new leader needs to be elected in case of the failure of an existing one.
• Log replication: The leader needs to keep the logs of all servers in sync with its own through replication.
• Safety: If one of the servers has committed a log entry at a particular index, no other server can apply a different log entry for that index.

Raft basics: the servers

A RAFT cluster consists of several servers – Typically five

Each server can be in one of three states

• Leader
• Follower
• Candidate (to be the new leader)

Followers are passive: – Simply reply to requests coming from their leader

Server states

Each server exists in one of the three states: leader, follower, or candidate.

• A Raft cluster typically contains 5 servers
• A server has three states •Leader, follower, and candidate
• Followers become candidates. Any candidate receiving a majority vote becomes a leader
• If the leader finds another leader or a server with a higher term id, it becomes a follower again.

Dividing Time into Terms

•Each server stores a current term number

•The term number is attached to every message

1. If a server with a lower term number sends a message to a server with a higher term number, the latter rejects the message
2. In the reverse case, the server with the lower term number upgrades its term num.
3. If a candidate or leader discover that their term is stale, they move to the follower state. •

RAFT protocol summary

Rules for Safety in the Raft protocol 

The Raft protocol guarantees the following safety against consensus malfunction by virtue of its design : 
 

• Leader election safety – At most one leader per term)
• Log Matching safety(If multiple logs have an entry with the same index and term, then those logs are guaranteed to be identical in all entries up through to the given index.
• Leader completeness – The log entries committed in a given term will always appear in the logs of the leaders following the said term)
• State Machine safety – If a server has applied a particular log entry to its state machine, then no other server in the server cluster can apply a different command for the same log.
• Leader is Append-only – A leader node(server) can only append(no other operations like overwrite, delete, update are permitted) new commands to its log
• Follower node crash – When the follower node crashes, all the requests sent to the crashed node are ignored. Further, the crashed node can’t take part in the leader election for obvious reasons. When the node restarts, it syncs up its log with the leader node