-
Notifications
You must be signed in to change notification settings - Fork 160
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
30cdf5f
commit 37d1da3
Showing
2 changed files
with
97 additions
and
0 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,47 @@ | ||
Summary: | ||
|
||
- Fixed: | ||
- [30cdf5fb](https://github.com/datafuselabs/openraft/commit/30cdf5fbc9275ce6213ca8f70cf37bc0c6fe957a) New leader must flush blank log. | ||
|
||
Detail: | ||
|
||
### Fixed: | ||
|
||
- Fixed: [30cdf5fb](https://github.com/datafuselabs/openraft/commit/30cdf5fbc9275ce6213ca8f70cf37bc0c6fe957a) New leader must flush blank log; by 张炎泼; 2024-05-14 | ||
|
||
This commit addresses a critical issue where if a new leader does not | ||
flush the blank log to disk upon becoming established and then restarts | ||
immediately, there is a possibility that previously committed data | ||
becomes invisible to readers. | ||
|
||
Before the blank log is flushed, the leader (identified by vote `v3`) | ||
assumes it will be flushed and commits this log once (|quorum|-1) | ||
replication responses are received. If the blank log is lost and the | ||
server is restarted, data committed by a new leader (vote `v2`) may | ||
not be visible. | ||
|
||
This issue is addressed by utilizing `LeaderHandler::leader_append_entries()` | ||
instead of `ReplicationHandler::append_blank_log()`, where the former | ||
does not wait for the blank log to flush. | ||
|
||
Changes: | ||
|
||
- When assigning log IDs to log entries, the `Leading.last_log_id`, | ||
which represents the state of the log proposer (equivalent term in | ||
Paxos is Proposer), should be used instead of `RaftState.last_log_id`, | ||
which represents the state of the log receiver (equivalent term in | ||
Paxos is Acceptor). | ||
|
||
- Consequently, the method `assign_log_ids()` has been moved from | ||
`RaftState` to `Leading`. | ||
|
||
- Avoid manual implementation of duplicated logic: | ||
|
||
- During `initialize()`, reuse `FollowingHandler::do_append_entries()` | ||
to submit the very first log to storage. | ||
|
||
- In `establish_leader()`, reuse | ||
`LeaderHandler::leader_append_entries()` to submit log to storage | ||
and remove `ReplicationHandler::append_blank_log()`. | ||
|
||
- Remove `Command::AppendEntry`. |