MySQL innodb engine architecture analysis - Double Write Buffer


Series Article Directory

1. MySQL innodb engine architecture analysis-Buffer Pool
2. MySQL innodb engine architecture analysis-Redo log
3. MySQL innodb engine architecture analysis-Double Write Buffer
4.MySQL innodb engine architecture analysis-Change Buffer


foreword

The size of one page of MySQL's buffer is 16K, and the size of one page of the file system is 4K. That is to say, MySQL needs to write 4 pages in the file system to flush one page of data in the buffer to the disk. The pages in MySQL were ready to be flushed to the disk, and only 3 pages in the file system were flushed. After power failure and restart, there were only 123 pages physically on the disk, and the data integrity was destroyed. If there is a "copy" to restore the original page, this kind of "page data corruption" problem can be solved. In MySQL, it is Double Write Buffer.
Redo Log cannot repair this kind of "page data damage" exception. The premise of repair is that "page data is correct." and the Redo Log log is normal. InnoDB's redo log will not record a complete page of data, because the log is too large, it will only record how (update, insert) which row (row) of which page (page) was operated at that time (sequence)


1. What is Double Write Buffer?

Double Write Buffer is a storage area of ​​the mysql system table space. In the system, Double Write is divided into two components: the double write buffer in the memory, and 128 consecutive pages in the shared table space on the physical disk, that is, 2 areas ( extent), the size is also 2MB.
insert image description here

Two, Double Write Buffer steps

step

insert image description here
(! Image source Baidu)

Before Innodb writes the data page to the data storage file, store the data page flushed from the Innodb cache pool. And only after the number is written into the doublewriter buffer, Innodb will perform physical storage of the data page. If the operating system, storage system, or myql process is interrupted when the data page is written to disk, InnoDB can retrieve the lost data page backup from the doublewriter buffer storage.
The first step: first memcopy the page data to the DWB memory;
the second step: in the DWB memory, it will first be flashed to the DWB disk;
the third step: in the DWB memory, and then flash to the data disk storage;

Impact on performance

The Double Write Buffer is a continuous physical space on the disk. The data in the memory is flushed to the Double Write Buffer, which belongs to sequential append writing, and the speed is very fast. Operation; third-party evaluation, assessing about 10% performance loss;


Summarize

If the data requirements of the system itself are not so high (such as log databases), Double Write Buffer double writing has a certain performance overhead. It can be turned off by the parameter innodb_doublewrite = 0, set to 1 means turned on. Officials believe that although the data needs to be written twice, the write buffer does not require two io overheads or operations, because only one call to fsync() of the operating system is required to sequentially write batch data to the disk -> system table space Double Write Buffer, here is sequential writing instead of random writing (performance can be guaranteed), of course, the premise is to configure the flush strategy parameter innodb_flush_method to the default O_DIRECT.
In actual production, it can also be controlled by parameters:
binlog_group_commit_sync_delay: The number of microseconds that the group commits to execute fsync() delay. The longer the delay time, the more batch data, and the less disk io, the higher the performance.
binlog_group_commit_sync_no_delay_count: The number of batches submitted by the group to execute fsync.

Guess you like

Origin blog.csdn.net/ren365880/article/details/128293324