WAL & Recovery

The page travelling from memory to disk, with the log that has to beat it there. Follows The Buffer Pool;

Before you start. The last lesson showed that the database keeps its own copies of pages in RAM and changes them there, not on disk, because touching RAM is roughly a thousand times faster than touching disk. That is also the danger this lesson exists to fix: a change that has only ever existed in RAM disappears completely the moment the machine loses power, before it ever reaches a disk file.

The idea in 30 seconds

A page’s change may never reach disk before the log entry describing it does - log first, page after, always.
The log is a running, append-only account of every change; after a crash the database rebuilds any page by replaying it.
COMMIT waits on exactly one thing: the log entry landing on physical disk, with the disk confirming it landed (an fsync). The changed page itself can wait.
Every so often the database writes all changed pages to disk and marks “everything before here is already safe” (a checkpoint), so a restart only redoes what happened after the newest mark.
A log that only ever lives on the machine that might get wiped isn’t much of a safety net: lose that disk and every change since the last backup is gone.

Read the story · Skip to the numbers