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
The need for preventing the ABA problem can be eliminated in the first place, if we delegate the unstable log to storage engine synchronously, and only assume flush/fsync is asynchronous [raft: clean unstable log early #122438].
We can remove various fields of raftpb.Message used only by this local protocol, to unclutter Message and make it smaller.
To support the new log write protocol, we are missing the notion of "leader term" - the term of the leader with whom our log is consistent. By raft invariants, all writes to, and acknowledgements from log storage are ordered by (leader term, index). Today, we approximate the "leader term" by using the last entry ID, but it complicates the protocol. It is also hard to reuse for Replication Admission Control because it requires remembering the unacknowledged entry IDs, but these are cleared from the unstable data structure as soon as the entries are written.
The plan is to support the "leader term" tracking:
The async log storage protocol (etcd-io/raft#8) can be improved in a few aspects:
unstablelog to storage engine synchronously, and only assume flush/fsync is asynchronous [raft: clean unstable log early #122438].raftpb.Messageused only by this local protocol, to unclutterMessageand make it smaller.To support the new log write protocol, we are missing the notion of "leader term" - the term of the leader with whom our log is consistent. By raft invariants, all writes to, and acknowledgements from log storage are ordered by
(leader term, index). Today, we approximate the "leader term" by using the last entry ID, but it complicates the protocol. It is also hard to reuse for Replication Admission Control because it requires remembering the unacknowledged entry IDs, but these are cleared from theunstabledata structure as soon as the entries are written.The plan is to support the "leader term" tracking:
raftLog/unstablestructuresMsgStorageAppend[Resp]messages to use the leader termMsgStorageAppend[Resp]messages protocol to a type-safe/ergonomicReady/ResponseAPI.Epic: CRDB-37515, CRDB-46488
Jira issue: CRDB-38897