I was going through the internals of MySQL, and I found something interesting called the doublewrite buffer, which is a smart hack to avoid data corruption; here’s what it’s all about
When you issue a write in MySQL (InnoDB), it does not write the data (page) directly to the disk at its final location. Instead, the engine
- first write the page to the on-disk doublewrite buffer
- ensures that the write is fsynced
- copy the page to their final location in the data file.
Why this extra step? This one extra step yields crash safety and atomicity.
Imagine the server crashed halfway while writing the page on the disk; it could corrupt the main data file and make recovery impossible, as we were overwriting the old page data.
But because InnoDB first writes to this separate buffer, we have a durable backup of the page (latest changes). Now, all the engine needs to do is a simple copy operation from the buffer to the main location.
If corruption happens during the final copy, InnoDB can just restore the page from the doublewrite buffer.
This adds some I/O overhead, but it’s a smart trade-off for keeping the data safe and gaining high durability and crash recovery. Super interesting.
btw, enrollments open for sys design Oct cohort for sde2+, ~35 seats left