Crash Recovery & Durability
What it is
Section titled “What it is”AetheriusDB is crash-recoverable. If the server loses power, is killed, or the machine reboots unexpectedly, the database comes back to its exact committed state on the next start — automatically. You do not run a recovery tool, replay a log by hand, or reconstruct anything.
Why it matters
Section titled “Why it matters”Durability you don’t have to operate is the whole point: a power loss, an OOM kill, or a reboot leaves you exactly where you were, with no runbook to follow. There’s no manual replay, no fsck-style repair pass, and no window where the database is up but wrong.
- No recovery tooling — the next start is the recovery; you don’t invoke anything.
- Committed means kept — anything acknowledged before the crash is there after it; nothing half-written is ever visible.
- Safe to kill — a hard kill is a supported way to stop; recovery handles it the same as a clean shutdown.
How fast it comes back
Section titled “How fast it comes back”Recovery is an instant load, not a log replay — the durable image is mapped back in and the database resumes serving queries, rather than grinding through a write-ahead log to reconstruct state.
What survives a crash
Section titled “What survives a crash”The guarantee is simple:
- Every committed transaction survives. A commit is only acknowledged after its data is durably on disk. If your client received a successful commit, that data is there after a crash.
- In-flight, uncommitted work is discarded. A transaction that had not committed when the power dropped is cleanly rolled back — you never see a half-applied write.
That is the whole contract for application code: if you got the commit ack, the data is safe.
How recovery behaves
Section titled “How recovery behaves”When the daemon restarts after a crash, it brings the database back on its own:
- It loads the most recent checkpoint.
- It applies the committed writes that happened after that checkpoint.
- It verifies integrity and opens for connections.
Because the work is bounded by the time since the last checkpoint — not by the
total age of the database — recovery is fast and stays fast as your data grows.
A clean shutdown (SIGTERM) checkpoints on the way out, so a normal restart skips
recovery entirely and opens almost immediately.
There is no manual log replay and no separate undo/redo step you have to supervise. You start the daemon; it comes back.
Checking status
Section titled “Checking status”You can force a checkpoint before a maintenance window and inspect what the engine did on the last start.
-- Force an immediate checkpoint (returns once durable).CHECKPOINT;
-- After a restart, see what recovery reconstructed.SHOW RECOVERY STATUS;After any unexpected hardware event — a power blip, a kernel panic, a disk replacement — you can run an integrity verification to get a definitive, read-only answer about whether your stored data is consistent.
-- Verify stored data integrity (read-only; safe to run anytime).VERIFY DATABASE analytics_prod;