Write-Ahead Logs
How databases write to a log first so no data is lost in a crash
What you'll learn
- A database as files on disk, and why updating them in place is slow and risky
- Appending to the WAL and changing the page cache
- Confirming a write once the WAL is on disk, and checkpoints
- Crash recovery, replicas and point-in-time restore
In this video, we'll look at how a database makes writes both fast and safe. We'll start with the simple picture: a database is a set of files on disk, and an update finds the file with the row, changes it and writes it back. That way is slow, and a crash in the middle of the write can leave a file half changed.
Then we'll see how the write-ahead log (WAL) fixes both: each change is added to the end of the WAL file and to the page cache in memory, the update is confirmed once the WAL is on disk, and a checkpoint later writes the changes into the data files in one batch. We'll also cover crash recovery from the WAL, replicas, and point-in-time restore.
By the end, you'll understand why databases write to a log first.
