Oct 24, 2024

A snapshot is a flushed copy of the table heads, concurrent with the flush to disk of all table bodies. A snapshot looks exactly like the “head” subdirectory and rotates between a “primary” and “secondary” folder. This ensures that once there is a good snapshot, a failed future snapshot can always revert to the previous good one. The purpose is to allow the store to revert to the point where the snapshot was taken, in the case of a process fault (uncontrolled termination). I also use it in development to roll the store back to certain points (such as post-sync and pre-validate, by storing a snapshot once synced, though on big machines we sync and validate concurrently). The node knows for sure when a previous shutdown has not been completed, and when it starts up will automatically recover from the most recent snapshot. If there is no snapshot it will currently require a manual restart after clearing the store. This gives us full fault tolerance, which leveldb (and most general database systems) cannot actually provide. This is pretty extraordinary given that the store is fully write/write and read/write concurrent.