Raft is a consensus algorithm designed for managing a replicated log across distributed systems. Its primary goal is to ensure that the log entries are replicated in a safe, consistent, and fault-tolerant manner. A critical event in the lifecycle of a Raft cluster is when a leader commits an entry to its log and subsequently crashes before it has had a chance to inform its followers of this commitment. Understanding how Raft handles such scenarios is vital to appreciating its robustness as a consensus mechanism.

Log Commitment and Crashes in Raft

When a leader in a Raft cluster commits a log entry, it first appends the entry to its log. The entry is then replicated to the follower nodes by sending AppendEntries RPCs. A log entry is considered committed when a majority of the cluster (i.e., the leader plus at least half of the followers) have written the entry to their logs. The leader keeps track of the highest log index that has been safely replicated, known as the commitIndex.

If a leader commits an entry but crashes before the commitment can be communicated to the followers, several safeguards and mechanisms within Raft ensure that the system remains consistent and can recover from such events:

1. Preservation of Log Across Elections: When a new leader is elected, it inherits the existing log entries, including those committed by previous leaders. This new leader will attempt to bring all followers' logs into consistency with its own.
2. Election Term as a Consistency Check: Each log entry in Raft is tagged with the term number (the leader's term when the entry was logged). During elections, each candidate sends its term and last log index to the voters (other nodes). Followers will deny their vote to a candidate if its log is less complete (either in terms of term or index) than their own log. This mechanism ensures that any elected leader will have all committed entries.
3. Log Matching Property Invariant: In Raft, it's guaranteed that if two logs contain an entry with the same index and term, then the logs are identical up to that index. This invariant helps in ensuring consistency across logs even if a leader crashes after committing entries.
4. Idempotency and Safety of AppendEntries: The AppendEntries RPCs are designed to be idempotent, meaning if they are sent multiple times (which might occur during retries after a leader crash), they do not cause any adverse effects. This allows the new leader to safely re-send AppendEntries from where the previous leader stopped.

Example Scenario

Consider a Raft cluster with 5 nodes. Suppose the leader (Node A) has committed a log entry at index $n$ and crashes immediately after. The remaining nodes may have the entry at index $n$ in various states - some might have written it to their log, and others might not have. A new leader election is triggered:

• Nodes with the log entry at index $n$ will have it with the committed term.
• When candidates for new leader send out RequestVote RPCs, only nodes which find the requesting node's log to be at least as up-to-date as their own will grant their vote.
• The newly elected leader will then ensure any missing entries, including the one at index $n$, are replicated to all nodes, respecting the commitIndex.

Key Points Summary

Conclusion

Through its election mechanism, log replication strategy, and carefully designed RPC operations, Raft ensures that even if a leader crashes immediately after committing an entry, the system's safety and consistency are preserved. A new leader, upon election, is responsible for maintaining the continuity and integrity of the log, thus allowing the cluster to recover smoothly from the crash without losing committed data. The robustness provided by Raft in handling leader crashes forms a core part of its appeal in distributed systems requiring high reliability.