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! The data file is caught half-written, but the note of intent is already safe on disk.
- 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.