The Runtime Theory

Crash Recovery: How the WAL Rebuilds Your Database

When a database crashes, the write-ahead log is the only source of truth. See how recovery locates the last checkpoint and replays committed records to rebuild a consistent state.

The Runtime Theory Team08 stages

trace / request.md

RESTART FINDSTORN STATEWAL IS THESOURCE OF TRUTHLAST CHECKPOINTNARROWS THE WORKCOMMITTED RECORDSARE REPLAYEDPARTIAL TRANSACTIONSROLL BACKPAGES MATCHCOMMITTED HISTORYFRESH CHECKPOINTWRITTENNORMAL OPERATIONRESUMES

readyOn restart, the database finds a torn state: buffer pool contents are gone, some data pages on disk are older than the log, and others were never flushed at all. Nothing is trusted.

The write-ahead log is not a backup; it is the database's memory. When the machine crashes, the buffer pool evaporates and the data pages on disk are an inconsistent mixture of old and new writes. This diagram is the recovery algorithm that turns that mess back into a database. The first step is finding the last checkpoint, which narrows the replay window; the second is redo, which replays every committed transaction's records forward; the third is undo, which walks back any transaction that never reached its commit record.

The order is load-bearing. Redo before undo, committed before uncommitted, checkpoint before replay — each stage assumes the previous one completed. And the whole design only works because the normal write path obeyed the log-first rule, so the log is always at least as current as any data page. That invariant, not the recovery code, is what makes durability real.