InnoDB Doublewrite Buffer
The doublewrite buffer writes dirty pages twice — first to a sequential scratch area, then to their real positions — so a torn page during a crash can be repaired from the intact copy.
Definition
The doublewrite buffer is an InnoDB reliability mechanism: before flushing a dirty page to its location in the tablespace, the engine writes it to a small sequential area in the system tablespace. If a partial page write occurs during a crash, the full copy in the doublewrite area restores it, keeping the redo-apply logic safe.
Context and scope
Tuned on write-heavy MySQL deployments, disabled in specialized setups with atomic-write guarantees or filesystem-level full-page writes, and a frequent suspect in write throughput discussions.
Common misconceptions
- Doublewrite protects against crashes in general — it specifically repairs torn or partial page writes that redo alone cannot recover
- It is pure overhead — it enables safe 16KB page flushes on filesystems without atomic write guarantees, and some SSDs and configs can safely disable it
- Redo log replay makes doublewrite redundant — redo assumes pages are physically intact; doublewrite guarantees that assumption
Anti-patterns
- Disabling doublewrite on a filesystem without atomic 16KB writes and risking unrecoverable corruption on power loss
- Attributing all write latency to doublewrite without measuring actual flush volume and filesystem behavior
- Mixing innodb_flush_method settings with doublewrite assumptions and silently changing the protection model
Related concepts
Authoritative source
https://dev.mysql.com/doc/refman/8.0/en/innodb-doublewrite-buffer.html
What it is
InnoDB stores data in 16KB pages and applies redo to pages assumed intact. Operating systems and devices may tear a large page write when power fails, leaving half-old half-new bytes that redo cannot fix. Doublewrite stages each page first into a sequential scratch region, then copies it into place.
How it works
On flush, pages accumulate in the doublewrite area and are written sequentially, then written again to their real offsets. Recovery finds torn pages and restores them from the scratch copy before redo. The sequential first pass also converts random page writes into larger sequential bursts, which some storage executes faster.
When to care
Default-on for good reason on commodity storage. Workloads with atomic-write SSDs, ZFS or filesystems providing full-page journaling, or replicated setups accepting rebuild-from-replica can evaluate disabling it, benchmarking both write throughput and crash recovery drills.
Pitfalls
The cost is real but bounded: extra sequential write volume, not doubled total writes. Disabling it on ext4 with default journaling trades a marginal gain for a real corruption risk. Measure with performance schema flush counters before and after any change.