Could Raft elect a leader with uncommitted log?

Question

Suppose a cluster of 5 nodes(ABCDE), node-A is elected leader at the beginning, and while leader-A issues AppendEntries RPCs to the follower(BCDE) to replicate log entry(log-X)，only node-B receives and returns success, at this point leader-A crashes.

If node C(or D or E) wins the next leader election then everything's fine, because only node B has log-X, and that means log-X is not committed.

My question is, could node-B (which has the highest term and longest log) win the next leader election? If so, will node-B spread log-X to other nodes?

Lugo

In your original question, if A returns the Client the fail response of log-X. Now the B win the leader and has the log-X, how to deal with log-X, according to my understanding the log should be discard because the old leader A return the fail response of log-X. If Leader B commit the log-x, then it will cause client data inconsistency – Trigg

Answer 1

Yes B could win the election, if it does become leader then the first thing it does it to create a log entry with the new term in its log, and start replicating its log to all the followers. As B's log includes log-X, if all goes well, eventually the log-X entry will be replicated & considered committed.

If node C wins the election, then when it becomes leader, it won't have the log-X entry, and it'll end up overwriting that entry on Node B.

See section 5.4.2 of the raft paper for more details.

Also this means you can't treat failure as meaning the attempted entry definitely doesn't exist, only that the caller doesn't know the outcome. Section 8 has some suggestions for handling this.

Yenta

thanks a lot, I still have a question: if leader-A received request to commit log-Y before A crashed, and it committed it by replicating log-Y to CDE(not B), now CDE's log is mmmY and B's log is mmm. And while leader-A replicating next log(log-X) to other nodes, only B receives and A crashes. Now B's log is mmmX, CDE's log is mmmY. B could still win the next election cause its log is up-to-date(index=4, term=A, same as others). But this could overwrite CDE's log to mmmX, wouldn't it be a problem because log-Y is considered committed? – Lugo

replication works backwards so b can't end up in that state. – Yenta

also append entries includes the index number, so it'll spot that there's a hole where Y was suposed to be. – Yenta

right, node B can be either mmmYX or mmm, can't be mmmX. thx~ – Lugo