When I study raft, I have a problem.
A Raft cluster has 5 servers. we call them a,b,c,d,e. a is the leader. Now everything is ok. Then, A handle a client request, makes a log entry.
scenario 1, b & c replicate the log entry, d & e don't. Then a & b crash. c has the log entry, d & e not. the log is committed.
scenario 2, b replicate the log entry, c, d, e don't. Then a & e crash. b has the log entry, c & d not. the log is not committed.
How raft handle them?
This statement "Then, A handle a client request, makes a log entry." should be extended to "Then, A handle a client request, A waits when at least 2 of (b,c,d,e) accept the request,[and then] makes a log entry."
Since there are five nodes - one leader and four followers - the majority requires three nodes: the leader and any two followers.
So, the leader adds entry to log when at least two followers accepted the request.
When a follower accepts a request, if does not mean the request is committed. A follower will commit a request only after the leader will tell it to do so.
From the context, "replicate" means that an entry was committed (in terms of raft). When a&b crash a new election process will have to happen. As usual, majority is needed to elect a new leader, hence all three (c, d, e) will communicate with each other.
Raft guarantees that a node with most up to date log wins an election. In our set (c,d,e) C has the most up to date log. Hence, C will be elected as a new leader. On election, C will send out the record missing from D and E.
When B (and the leader) have the log entry, the record is not committed as no majority accepted the entry. On failure, new election will happen and B will win the election, same as in scenario 1.