How MySQL Doublewrite Buffer Prevents Partial Page Writes

This article explains how the MySQL InnoDB storage engine utilizes the doublewrite buffer to protect database integrity against partial page writes. You will learn about the mechanics of this feature, why standard recovery methods fall short during operating system crashes, and how this buffer acts as a safety net to prevent data corruption.

The Problem of Partial Page Writes

To understand how the doublewrite buffer works, you must first understand the vulnerability it solves: partial page writes, also known as torn pages.

The InnoDB storage engine manages data in pages, which are typically 16KB in size by default. However, most operating systems and file systems write data to disk in much smaller blocks, usually 4KB. When MySQL writes a 16KB page to disk, the operating system must perform four distinct physical write operations.

If a system crash, power outage, or hardware failure occurs midway through this process, only a portion of the 16KB page might be written to disk. The resulting page on disk is left in an inconsistent, corrupted state—partially updated and partially outdated.

Why Redo Logs Cannot Fix Torn Pages

MySQL uses a write-ahead log called the redo log to recover from crashes. However, the redo log cannot recover a page that has suffered a partial write.

Redo logs contain physiological logs, which record changes made to pages rather than the entire page itself. To apply a redo log during recovery, InnoDB requires the target page on disk to be in a physically consistent state. If a page is torn (corrupted), the redo log cannot be applied because the base state of the page is destroyed.

How the Doublewrite Buffer Resolves the Issue

The doublewrite buffer is a storage area where InnoDB writes pages before writing them to their actual positions in the data files. It consists of a memory buffer and a contiguous segment of physical disk space (usually within the system tablespace or separate doublewrite files).

The prevention process works in the following sequential steps:

1. Buffering in Memory: When dirty pages in the InnoDB buffer pool need to be flushed to disk, they are first copied to the doublewrite buffer in memory.
2. Sequential Disk Write: The pages in the doublewrite buffer are written to the physical doublewrite buffer on disk using sequential I/O. Because the write is contiguous, it is highly efficient.
3. Data File Write: Once the write to the doublewrite buffer is successfully completed and synced to disk, InnoDB writes the pages to their actual locations in the data files (using random I/O).

The Crash Recovery Process

If a crash occurs during this process, the doublewrite buffer ensures data can be recovered safely:

• Crash during the actual data file write: If the server crashes while writing pages to their final locations, the pages on disk may be torn. During startup, InnoDB checks the doublewrite buffer. Since the pages were safely written to the doublewrite buffer before the crash, InnoDB copies the intact pages from the doublewrite buffer over the torn pages in the data files. This restores the pages to a consistent state, allowing the redo logs to be applied normally.
• Crash during the doublewrite buffer write: If the server crashes while writing to the doublewrite buffer itself, the pages in the actual data files remain completely untouched and uncorrupted. MySQL can simply ignore the incomplete doublewrite buffer writes and reconstruct the changes using the redo log.