The Torn Page Problem
A database page is larger than the unit the disk writes atomically. If a crash strikes mid write, the page on disk can be torn: part new, part old. The redo log assumes a known starting page to apply changes to, so a torn page can leave recovery unable to repair the data.
The Solution
The doublewrite buffer writes each dirty page twice. First the engine writes a batch of pages sequentially to a dedicated doublewrite area, flushing it. Only then does it write each page to its real location.
- If a crash tears a page at its final location, recovery finds an intact copy in the doublewrite area.
- The clean copy is written over the torn page, then redo replays normally.
- The doublewrite area is sequential, so the second write is cheaper than its size suggests.
When You Can Skip It
If the storage already guarantees atomic page writes, the doublewrite buffer is redundant and can be disabled for speed. Otherwise it is the safety net that makes redo recovery sound.
Key idea
The doublewrite buffer writes each page to a sequential safe area before its real location, so a torn write after a crash can be repaired from the intact copy before redo runs.