You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original Raft implementation does not have rollbacks. Therefore when there is a change in the leader (primary) there is no need to update last_idx (which tells us the local un-committed index).
This can lead to nodes thinking that they are further ahead than they actually are after an election with last_idx being ahead of commit_idx. The fact that the ledger is not being truncated on rollback makes the newly elected leader able to communicate entries that are, in fact, rolled back.
The text was updated successfully, but these errors were encountered:
Our current logic will not retransmit these old entries though, the fact that the ledger isn't truncated is theoretical, the old entries will be overwritten, and there's no impact on integrity.
The impact of using the log_idx is that the election selects a ledger on irrelevant grounds, since it will be rolled back to the last commit idx.
Original Raft implementation does not have rollbacks. Therefore when there is a change in the leader (primary) there is no need to update
last_idx
(which tells us the local un-committed index).This can lead to nodes thinking that they are further ahead than they actually are after an election with
last_idx
being ahead ofcommit_idx
. The fact that the ledger is not being truncated on rollback makes the newly elected leader able to communicate entries that are, in fact, rolled back.The text was updated successfully, but these errors were encountered: