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
{{ message }}
This repository has been archived by the owner on Dec 17, 2018. It is now read-only.
The libraft log can grow without bound. Log compaction (i.e. snapshots) are necessary to address this. With compaction the current state is dumped to disk and log entries subsumed by this state are removed.
There are two high-level options here:
Snapshots are triggered without coordination on each server. Logs and snapshots may be different on different servers. Leaders have to send snapshots and followers have to process them. Snapshots have to be loaded on startup to prime the caller's state.
Leader triggers snapshot for the cluster. This maintains a high-degree of log coherency, but I don't think it adds much value. It requires coordination, and you still need all the messages and logic required for the first option.
Tasks
Take snapshots.
Load a mix of snapshots and log entries on startup.
Automatically trigger taking a snapshot.
Send snapshot to followers (RPCSender API, ordering, tests, etc.).
Receive snapshot from leader (RPCReciever API, ordering, tests, etc.).
Store new snapshot
Truncate log entries on receiving snapshot.
Clean up stale snapshots.
Truncate log entries on taking snapshot.
The text was updated successfully, but these errors were encountered:
The libraft log can grow without bound. Log compaction (i.e. snapshots) are necessary to address this. With compaction the current state is dumped to disk and log entries subsumed by this state are removed.
There are two high-level options here:
Tasks
RPCSender
API, ordering, tests, etc.).RPCReciever
API, ordering, tests, etc.).The text was updated successfully, but these errors were encountered: