-
Notifications
You must be signed in to change notification settings - Fork 21
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Ensure Consistent LSN Before Opening for Traffic in Raft Group
We identified a gap when majority members in a Raft group are down. To save IO operations, we do not persist the last_commit_idx for every commit but instead at regular intervals. Consequently, upon reboot, we may not reflect the latest commit, leaving some logs in the state machine waiting for re-commitment. For instance, if we committed up to LSN 103 but only persisted up to LSN 100, then LSNs 100-103 will remain in the log-store, awaiting re-commitment from the leader. If all members restart after a disaster, they face the following state: - [S1]: commit_idx 100, last_log {idx = 105, term = 1} - S2: commit_idx 100, last_log {idx = 103, term = 1} - S3: commit_idx 100, last_log {idx = 103, term = 1} If S1 opens for traffic at this point, previously committed LSN 102 might return NOT_FOUND to clients due to the uncommitted state. Proposed Solution: - Mark last_log_idx as `traffic_ready_lsn` in the BECOME_LEADER callback. In the example above, it is 105 if S1 becomes the leader. - The leader will not accept IO until it commits up to this `consistent_lsn` (105), ensuring correctness by over-committing. - The HO will call `repl_dev->is_ready_for_traffic()` for each IO. - On followers, the traffic_ready_lsn is zero so it allows all. - On the leader, all requests are rejected until it commits to the `traffic_ready_lsn` (105 in this example). Signed-off-by: Xiaoxi Chen <[email protected]>
- Loading branch information
1 parent
707c111
commit 0de97cd
Showing
8 changed files
with
67 additions
and
15 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters