Ticketing Snapshot
A node too far behind to catch up via the log (e.g. right after a restart) is sent the entire current state via the FullSnapshot RPC. Inside snapshot_bytes is the following structure, serialized with postcard.
| Field | Content |
|---|---|
last_applied | The last log position this snapshot reflects |
last_membership | Membership (node composition) info |
token_seq | The fencing-token issuance counter — replicated, so token monotonicity holds even across a leader change |
locks | A list of (key, token, remain_ms) — every held lock and its remaining lease |
remain_msis the remaining lease, in milliseconds, at the moment the snapshot was taken. The node installing it restores the expiry time asnow + remain_mson its own clock — no absolute timestamp is ever sent, so clock drift between nodes has no effect.- Milliseconds are used only here, for precision (the client-facing unit is seconds).
- The Raft log is in-memory (volatile). A restarted node boots with empty state, then catches up via a peer's log replication or this snapshot — committed state is preserved as long as a majority stays alive.
Flow
Leader
Lagging node
right after restart — boots with empty state
AppendEntries
too far behind to catch up via the log
FullSnapshot — entire state in one frame
installs: restores each lock as now + remain_ms
back to plain AppendEntries log entries
consensus RPC (Raft)
Terminology
- snapshot — a full copy of the state at a specific point in time. It lets a lagging node install the snapshot and follow only the log entries after it, instead of replaying everything from scratch.
- membership — the list of nodes that make up the cluster and their role information.