This fix ensures that counting of replicas to determine a new commit value only considers entries replicated as part of the current term.
closes#108
Co-authored-by: Anthony Dodd <Dodd.AnthonyJosiah@gmail.com>
This adds `30s + rand_election_timeout` to a node's initial
next_election_timeout when the node has recovered state after a restart.
This helps to ensure that the node does not trigger a new election and
begin driving up the Raft term before it can even properly communicate
with peers.
Fixed a few clippy lints.
This is a farily minimal changeset, but is a breaking change.
This introduces a `RaftStorage::ShutdownError` associated type.
This allows for the Raft system to differentiate between fatal storage
errors which should cause the system to shutdown vs errors which should
be propagated back to the client for application specific error handling.
These changes only apply to the
`RaftStorage::apply_entry_to_state_machine` method.
Overall, this constitutes a nice improvement to the RaftStorage
interface, as a flat result type may be used for propagating errors. No
result nesting required.
- Use https://github.com/actions-rs/clippy-check action for better reporting.
- Run clippy with latest stable Rust instead of old version
- Run clippy against all targets including test cases.
This is especially needed for cases where interaction with Raft from the
parent app needs to spawn a task for interacting with Raft. This makes
the interface a bit more flexible overall.
The log index provided to the log compaction interface was a bit
misleading. When performing log compaction, the compaction can only
cover the breadth of the log up to the last applied log (obvs) and under
write load, this value may change quickly. As such, the expectations of
the log compaction interface have been refined and clarified.
Now, the only expectation is that the storage implementation will
export/checkpoint/snapshot its state machine, and then use the value of
that export's last applied log as the metadata indicating the breadth of
the log covered by the snapshot.
With this change, we are also caching entries which come from the leader
replication protocol. As entries come in, we append them to the log and
then cache the entry. When it is safe to apply entries to the state
machine, we will take them directly from the in-memory cache instead of
going to disk.
Moreover, and most importantly, we are not longer blocking the
AppendEntries RPC handler with the logic of the state machine
replication workflow. There is a small amount of async task juggling to
ensure that we don't run into situations where we would have two writers
attempting to write to the state machine at the same time. This is
easily avoided in our algorithm.
closes#12closes#76
Anthony Dodd
张炎泼
linsinn
iamazy
Cheng XU
Sunli