Replies: 1 comment
-
The snapshot file contains the current state of the service at a point in time, but not the historical state. To start a node from a snapshot, it needs both the snapshot itself and proof that the snapshot was committed - the latter currently comes from the ledger directory, where the node looks at transactions after the snapshot index until it finds commit proof. In future we will combine these into a single file, a snapshot with proof, so that single file can be used to launch a node. Starting a node from a snapshot like this should be faster than starting from a ledger, since it does not need to replay the entire history to derive the current state. However, if the node doesn't have access to a copy of the ledger, it will not be able to answer historical queries. Specifically, it cannot return state for any transaction index earlier than the start of the ledger it has access to. Note that it is possible to be started with both a snapshot and a ledger, so the node boots quickly but is also still able to serve historical queries. If a node is started from from a full ledger but no snapshot, it should function correctly but may take longer to catch up (reach the commit index). Do you have error logs from your |
Beta Was this translation helpful? Give feedback.
-
We tried disaster recovery and and here are our finding during our trials and we want to use following option.
What we will loose from above approach if we will try to recover using all ledger files instead of snapshot ?
Why i cant just recover from snapshot and empty ledger file, our older version of cchost crashes if we try to recover from empty ledger directory and just specifying snapshot. Unfortunately we are using old version of CCF and in latest behavior might be different now.
Beta Was this translation helpful? Give feedback.
All reactions