v0.9.11

[drmingdrmer]

Summary:

• Fixed:
  • 30cdf5fb New leader must flush blank log.

Detail:

Fixed:

• Fixed: 30cdf5fb 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.

---

This discussion was created from the release v0.9.11.