Understanding the InnoDB Doublewrite Buffer

The InnoDB Doublewrite Buffer is one of those features that quietly keeps your MySQL data safe without anyone noticing — until something goes wrong. It protects against torn page writes, a subtle form of corruption that can occur when a system crashes in the middle of writing a 16KB InnoDB page to a storage device that uses a smaller atomic write size (typically 512 bytes or 4KB).

In this post, we'll break down how the Doublewrite Buffer works, why it exists, and the implications of disabling it.

The Problem: Torn Pages

InnoDB stores data in pages that are 16KB by default. Most operating systems and storage devices, however, guarantee atomicity only at the sector level — 512 bytes or 4096 bytes. This means that when InnoDB flushes a 16KB page to disk, it involves multiple smaller write operations under the hood.

If the system crashes between those writes — a power failure, kernel panic, or OOM kill — you can end up with a page that is only partially written. The first half might contain new data, the second half old data. InnoDB's crash recovery cannot fix this using the redo log alone, because the redo log assumes the original page on disk is intact to apply changes on top of.

A torn page is essentially half-old, half-new — and the redo log has no way to know which half is which.

The Solution: The Doublewrite Buffer

InnoDB solves this with a two-phase write approach:

Phase 1 — Sequential write to the Doublewrite Buffer: Before flushing dirty pages to their actual locations in the tablespace, InnoDB writes them sequentially to a dedicated area called the Doublewrite Buffer. Sequential writes are more atomic-friendly and faster on traditional HDDs.
Phase 2 — Write to actual tablespace positions: Once the Doublewrite Buffer is safely flushed, InnoDB writes each page to its real location in the data file.

If a crash happens during Phase 2, InnoDB can recover by reading the complete, known-good copy of the page from the Doublewrite Buffer and using it as the base for redo log application.

Where Is It Stored?

Historically, the Doublewrite Buffer was stored inside the system tablespace (ibdata1). Since MySQL 8.0.20, it has been moved to its own dedicated files, separate from the system tablespace, which improves I/O efficiency:

# Default location in MySQL 8.0.20+
ls -lh /var/lib/mysql/#ib_16384_0.dblwr
ls -lh /var/lib/mysql/#ib_16384_1.dblwr

You can configure the location with the innodb_doublewrite_dir variable, useful if you want to put it on a faster or more durable storage device.

Checking the Status

You can verify the Doublewrite Buffer status and see its activity via:

SHOW GLOBAL STATUS LIKE 'Innodb_dblwr%';

+----------------------------+----------+
| Variable_name              | Value    |
+----------------------------+----------+
| Innodb_dblwr_pages_written | 18430    |
| Innodb_dblwr_writes        | 4107     |
+----------------------------+----------+

The ratio of Innodb_dblwr_pages_written to Innodb_dblwr_writes tells you how many pages are being batched per write. A higher ratio means better efficiency.

Should You Disable It?

You can disable the Doublewrite Buffer with:

SET GLOBAL innodb_doublewrite = OFF;
# or in my.cnf:
innodb_doublewrite = 0

This gives a modest performance boost — typically 5–15% on write-heavy workloads — because you eliminate one full write cycle per flush. Some scenarios where disabling is reasonable:

Your filesystem or storage guarantees atomic writes at the 16KB level (e.g., ZFS with a matching recordsize, or some NVMe devices with native 16KB atomicity)
You're running a non-critical environment where you can afford to recreate data from backups
You're using MySQL as a replica where the primary is authoritative

For most production systems, keep it enabled. The performance cost is low, the protection it provides is real, and it has saved more than a few databases from silent corruption after unexpected crashes.

Conclusion

The InnoDB Doublewrite Buffer is a simple but effective mechanism to protect against a real class of corruption. It adds a modest write overhead in exchange for the guarantee that a crash during a page flush won't leave your data in an unrecoverable state. Unless you have a very specific reason backed by your storage stack's guarantees, leave it on.

Have questions or a different experience with the Doublewrite Buffer in production? Feel free to reach out.