Log first, apply second
A write ahead log, or WAL, records the description of a change before that change is applied to the main data structures. If the system crashes mid operation, recovery replays the log to finish or discard partial work, so data is never left inconsistent.
Why ordering matters
The rule is strict: the log entry for a change must be durably on disk before the corresponding data pages are written. That ordering is what guarantees recovery can always reconstruct a consistent state.
How recovery works
After a crash the system reads the WAL from the last known good point:
- Redo committed changes that may not have reached the main data files.
- Undo uncommitted changes that should never have been visible.
This brings the database back to the state of the last committed transaction.
Performance angle
The WAL turns scattered random updates into one sequential append, which is fast. The actual data pages can be flushed lazily in the background. A checkpoint periodically marks how far the log has been applied so recovery has less to replay and old log can be trimmed.
Key idea
A write ahead log durably records intent before mutating data, so a crash can be recovered by redoing committed and undoing uncommitted changes, while also turning random updates into fast sequential writes.