Write-ahead log (WAL).
Jot the move in a notebook before you make it, so a crash can’t lose it.
A careful shopkeeper writes every sale in a ledger the instant it happens, before stocking the shelf or counting the till. If the lights go out mid-task, the ledger still shows exactly what was meant to happen, so nothing is lost and nothing is half-done.
A write-ahead log is that ledger for a database. Before changing the real data, it first records the intended change to an append-only log on disk. If the system crashes, it replays the log on restart and ends up exactly where it should be.
- Note it first.1
About to make a change. First, write down exactly what you intend to do.
- 2
Only once the note is safely on disk do you touch the real data.
- 3
Crash! Power cuts out partway through.
- Replaying…4
On restart, replay the log — every recorded change is reapplied. Nothing lost.
- 5
The log is append-only, so writes are fast sequential ones, not scattered.
- 6
It keeps growing, so the system checkpoints and trims it now and then.
Why write twice
Updating data in place is risky: a crash can catch a record half-written, leaving it corrupt. Writing the intention first means there is always a complete, ordered record of what should happen. Even if the real update is interrupted, the log lets the database finish or redo it cleanly on restart. This is the “D” — durability — in ACID.
A free speed-up
Appending to the end of a file is one of the fastest things a disk can do, far quicker than hopping around to update scattered records. So the log doubles as a performance trick: commit quickly by appending, then apply the slower in-place updates in the background. The same idea powers replication, since the log is a perfect change-feed to ship to other machines.