Skip to main content

Module swap_db

Module swap_db 

Source
Expand description

Stay-readable re-bootstrap with an atomic dataset swap (issue #837, PRD #819).

When a replica must re-bootstrap — discard its current dataset and load a fresh snapshot from the primary — it must not go dark. Read capacity is most precious exactly then, because a re-bootstrap is often triggered because another node is already down. SwapDb keeps the old data fully readable for the entire rebuild and swaps to the fresh dataset in one atomic step at the end.

§The two-state guarantee

  • Stay-readable. Non-causal reads (SwapDb::read_noncausal) are always served from the currently-installed dataset — the old data throughout the rebuild, the new data after the swap. They never block and never fail.
  • Causal correctness. While a rebuild is in flight the node’s applied frontier describes data it is about to throw away, so a bookmark read served from it could observe a commit that the post-swap dataset has not yet reached. SwapDb::read_causal therefore refuses (RebootstrapInProgress) for the duration of the rebuild; the caller routes that read to a caught-up peer. The same signal is surfaced on the wire via crate::replication::primary::ReplicaState::rebootstrapping so the client routing table excludes the node before the read ever reaches it.

§Atomicity

The installed dataset is an Arc<D> behind an RwLock. A reader clones the Arc under a short read lock and then works against its own handle. SwapDb::complete_rebootstrap takes the write lock just long enough to replace the pointer. A reader that captured the old Arc before the swap keeps observing a complete old dataset; a reader that captures after the swap sees a complete new one. There is no window in which a half-built dataset is visible — the swap publishes the fresh D only once it is fully constructed.

Structs§

RebootstrapInProgress
A causal read was requested while the node is re-bootstrapping.
SwapDb
A dataset that stays readable across an atomic re-bootstrap swap.