[regularfry]

Yes, they have the log entry, but it can still be rolled back, can't it? Here's how I understand the process:

1. Client sends log entry to leader

2. Leader appends log entry, forwards it to followers

3. Majority of followers confirm

4. Leader commits the log entry

5. Leader confirms the commit to the client

6. Followers commit on the next heartbeat

What happens if the leader goes away between 5 and 6? To my eyes, it looks like the followers will time out, elect a new leader, and have to roll back the last log entry.

[DanWaterworth]

If an entry has been replicated to a majority of followers, then the new leader is guaranteed to have that entry and therefore it won't be rolled back.

[regularfry]

How does the new leader know it went to a majority? The only entity which could confirm that is the old leader.

[Muzzaf]

That is correct. The solution to this is given in section 5.4.1 (election restriction), section 5.4.2 (Committing entries from previous terms) and section 8 (Client interaction) of the Raft paper.

Roughly, a newly elected leader will have all committed entries (guaranteed by the "election restriction", 5.4.2) but it does not know precisely which are committed. The new leader will commit a no-op log entry (section 8) and after it has received replies from a majority of the cluster it will know which entries have already been committed.

[regularfry]

Ooh, thanks. The no-op commit is particularly interesting.