|
11 | 11 | {-# LANGUAGE ScopedTypeVariables #-} |
12 | 12 | {-# LANGUAGE TypeApplications #-} |
13 | 13 |
|
14 | | --- | Common logic and types for LedgerDB Snapshots. |
| 14 | +-- | Snapshots |
15 | 15 | -- |
16 | | --- Snapshots are saved copies of Ledger states in the chain which can be used to |
17 | | --- restart the node without having to replay the whole chain. Regardless of the |
18 | | --- actual LedgerDB implementation chosen, the general management of snapshots is |
19 | | --- common to all implementations. |
| 16 | +-- Snapshotting a ledger state means saving a copy of the state on disk, so that |
| 17 | +-- a later start of a cardano-node can take such snapshot as an starting point |
| 18 | +-- instead of having to replay from Genesis. |
| 19 | +-- |
| 20 | +-- A snapshot is identified by the slot number of the ledger state it contains |
| 21 | +-- and possibly has a suffix in the name. The consensus logic will not delete a |
| 22 | +-- snapshot if it has a suffix. This can be used to store important snapshots. |
| 23 | +-- |
| 24 | +-- In general snapshots will be stored in the @./ledger@ directory inside the |
| 25 | +-- ChainDB directory, but each LedgerDB backend is free to store it somewhere |
| 26 | +-- else. Management of snapshots is done through the 'SnapshotManager' |
| 27 | +-- record. |
| 28 | +-- |
| 29 | +-- Snapshots are composed from two differentiated parts: |
| 30 | +-- |
| 31 | +-- - the ledger state tables: location and format differs among backends, |
| 32 | +-- |
| 33 | +-- - the rest of the ledger state: a CBOR serialization of an @ExtLedgerState |
| 34 | +-- blk EmptyMK@, stored in the @./state@ file in the snapshot directory. |
| 35 | +-- |
| 36 | +-- V2 backends will provide means of loading a snapshot via the method |
| 37 | +-- 'newHandleFromSnapshot'. V1 backends load the snapshot directly in |
| 38 | +-- 'initFromSnapshot'. |
20 | 39 | module Ouroboros.Consensus.Storage.LedgerDB.Snapshots |
21 | 40 | ( -- * Snapshots |
22 | 41 | CRCError (..) |
|
0 commit comments