Skip to content

Commit 37d1da3

Browse files
committed
Doc: add change-log 0.9.11
1 parent 30cdf5f commit 37d1da3

File tree

2 files changed

+97
-0
lines changed

2 files changed

+97
-0
lines changed

change-log.md

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,53 @@
1+
## v0.9.11
2+
3+
Summary:
4+
5+
- Fixed:
6+
- [30cdf5fb](https://github.com/datafuselabs/openraft/commit/30cdf5fbc9275ce6213ca8f70cf37bc0c6fe957a) New leader must flush blank log.
7+
8+
Detail:
9+
10+
### Fixed:
11+
12+
- Fixed: [30cdf5fb](https://github.com/datafuselabs/openraft/commit/30cdf5fbc9275ce6213ca8f70cf37bc0c6fe957a) New leader must flush blank log; by 张炎泼; 2024-05-14
13+
14+
This commit addresses a critical issue where if a new leader does not
15+
flush the blank log to disk upon becoming established and then restarts
16+
immediately, there is a possibility that previously committed data
17+
becomes invisible to readers.
18+
19+
Before the blank log is flushed, the leader (identified by vote `v3`)
20+
assumes it will be flushed and commits this log once (|quorum|-1)
21+
replication responses are received. If the blank log is lost and the
22+
server is restarted, data committed by a new leader (vote `v2`) may
23+
not be visible.
24+
25+
This issue is addressed by utilizing `LeaderHandler::leader_append_entries()`
26+
instead of `ReplicationHandler::append_blank_log()`, where the former
27+
does not wait for the blank log to flush.
28+
29+
Changes:
30+
31+
- When assigning log IDs to log entries, the `Leading.last_log_id`,
32+
which represents the state of the log proposer (equivalent term in
33+
Paxos is Proposer), should be used instead of `RaftState.last_log_id`,
34+
which represents the state of the log receiver (equivalent term in
35+
Paxos is Acceptor).
36+
37+
- Consequently, the method `assign_log_ids()` has been moved from
38+
`RaftState` to `Leading`.
39+
40+
- Avoid manual implementation of duplicated logic:
41+
42+
- During `initialize()`, reuse `FollowingHandler::do_append_entries()`
43+
to submit the very first log to storage.
44+
45+
- In `establish_leader()`, reuse
46+
`LeaderHandler::leader_append_entries()` to submit log to storage
47+
and remove `ReplicationHandler::append_blank_log()`.
48+
49+
- Remove `Command::AppendEntry`.
50+
151
## v0.9.10
252

353
Summary:

change-log/v0.9.11.md

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
Summary:
2+
3+
- Fixed:
4+
- [30cdf5fb](https://github.com/datafuselabs/openraft/commit/30cdf5fbc9275ce6213ca8f70cf37bc0c6fe957a) New leader must flush blank log.
5+
6+
Detail:
7+
8+
### Fixed:
9+
10+
- Fixed: [30cdf5fb](https://github.com/datafuselabs/openraft/commit/30cdf5fbc9275ce6213ca8f70cf37bc0c6fe957a) New leader must flush blank log; by 张炎泼; 2024-05-14
11+
12+
This commit addresses a critical issue where if a new leader does not
13+
flush the blank log to disk upon becoming established and then restarts
14+
immediately, there is a possibility that previously committed data
15+
becomes invisible to readers.
16+
17+
Before the blank log is flushed, the leader (identified by vote `v3`)
18+
assumes it will be flushed and commits this log once (|quorum|-1)
19+
replication responses are received. If the blank log is lost and the
20+
server is restarted, data committed by a new leader (vote `v2`) may
21+
not be visible.
22+
23+
This issue is addressed by utilizing `LeaderHandler::leader_append_entries()`
24+
instead of `ReplicationHandler::append_blank_log()`, where the former
25+
does not wait for the blank log to flush.
26+
27+
Changes:
28+
29+
- When assigning log IDs to log entries, the `Leading.last_log_id`,
30+
which represents the state of the log proposer (equivalent term in
31+
Paxos is Proposer), should be used instead of `RaftState.last_log_id`,
32+
which represents the state of the log receiver (equivalent term in
33+
Paxos is Acceptor).
34+
35+
- Consequently, the method `assign_log_ids()` has been moved from
36+
`RaftState` to `Leading`.
37+
38+
- Avoid manual implementation of duplicated logic:
39+
40+
- During `initialize()`, reuse `FollowingHandler::do_append_entries()`
41+
to submit the very first log to storage.
42+
43+
- In `establish_leader()`, reuse
44+
`LeaderHandler::leader_append_entries()` to submit log to storage
45+
and remove `ReplicationHandler::append_blank_log()`.
46+
47+
- Remove `Command::AppendEntry`.

0 commit comments

Comments
 (0)