Node recovery
#6669
Replies: 1 comment 1 reply
-
Yes
Yes. Snapshots are unlikely to be sufficient if your goal is to avoid losing committed data, since they are produced at a configurable interval, not for every transaction. You will want at least one snapshot + ledger files since. And if you want to be able to service historical queries further back, the full ledger. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Looking for an interim option to stand minimal footprint (single node for near term).
Can single node be recovered from snapshots to reload all committed transactions assuming uncommitted would be lost?
Assuming the service certificate would change and hence needs to be to propagated to clients similar to DR. Will the node be able to recover all transactions that where committed?
Reference - Recover sample config
Tried curating a recovery configuration and restart the node with the old service identity. The node recovers but the "node/network" curl implies the node is waiting on
"service_status": "WaitingForRecoveryShares"
.{ "current_service_create_txid": "4.20", "current_view": 4, "primary_id": "ec2befcca7216873fc68344e398f567ac6673f13fb272272a56ffc2753fcf20d", "recovery_count": 1, "service_certificate": "*****", "service_data": null, "service_status": "WaitingForRecoveryShares" }
Not clear what is the right architecture and operation procedure here. Should the operations follow Disaster Recovery ?
If DR is required, should both ledger.dir & snapshot be persisted and mounted appropriately during recovery ? Does recovery use both sets of files or snapshot is sufficient?
Beta Was this translation helpful? Give feedback.
All reactions