Doublewrite buffer
An InnoDB doublewrite buffer stages data-page copies before their final file writes so crash recovery can repair an incomplete page write.
MySQL 8.4 ON and DETECT_AND_RECOVER preserve page content, while DETECT_ONLY preserves metadata without repair bytes. Changes among these enabled modes can be dynamic, but switching between an enabled mode and OFF cannot. [4]
In mysql-8.4.0, reduced entries contain tablespace ID, page number and LSN. Recovery can fail on a corrupt page when no full copy has repaired it. A recorded page identity is not a recovery image. [3]
Redo logging remains separate: it records changes for replay, whereas the staged page supplies reconstruction material. A successfully repaired page does not decide whether its transaction committed. [2] [5]
Relations
- related
- torn-write, full-page-write, write-ahead-log, database-checkpoint, crash-consistency
Advantages
- Sequential batching shares synchronization work across pages instead of requiring a separate flush per staged page. [1]
Limitations
- Additional page writes consume bandwidth; the mechanism is not an independent backup or protection against every corruption source. [1]
Citations
- MySQL 8.4: Doublewrite Buffer, page-copy recovery and batched writes
- MySQL 8.4: Redo Log, recovery records and checkpoint progress
- MySQL mysql-8.4.0: buf0dblwr.cc, reduced_recover and page recovery
- MySQL 8.4: InnoDB variables, innodb_checksum_algorithm and innodb_doublewrite
- MySQL 8.4: InnoDB Recovery, redo application and background transaction rollback
Further reading
Sources & caveats
- Behavior is scoped to the MySQL 8.4 manual and mysql-8.4.0 implementation, not all engines or future releases.
- The description is a documentation and code review, not a power-loss experiment or throughput benchmark.