MySQL：脏页刷盘

Posted 2023-04-01

参考技术A

InnoDB在处理更新语句时，先写内存再写redo log，并不会立即将数据页的更新落地到磁盘（WAL机制），这就会产生升内存数据页和磁盘数据页的数据不一致的情况，这种数据不一致的数据页称为 脏页 ，当脏页写入到磁盘（这个操作称为flush）后，数据一致后称为干净页。

第3种是系统空闲不会有性能问题，第4种是要关闭了不考虑性能问题。第1和2的情况flush脏页会产生系统性能问题。

此时整个系统不能再更新了，更新数会降为0，所以这种情况要尽量避免。

InnoDB缓冲池（buffer pool）中的内存页有三种状态：

当一个SQL语句要淘汰的脏页数量太多，会导致语句执行的响应时间显著边长。

InnoDB为了避免出现上述两种情况，需要有控制脏页比例的策略，控制的主要参考因素就是：脏页比例和redo log写盘速度。

需要告诉InnoDB的磁盘读写能力（IOPS）让引擎全力flush脏页，磁盘的IOPS可以通过fio工具测试。

如果 innodb_io_capacity 参数设置的不合理，比如远远低于磁盘实际的IOPS，InnoDB会认为IO性能低，刷脏页速度会很慢，甚至低于脏页的生成速度，导致脏页累计影响查询和更新性能。

为了兼顾正常的业务请求，InnoDB引擎控制按照磁盘IOPS的百分比来刷脏页，具体流程如下：

脏页比例计算:
Innodb_buffer_pool_pages_dirty/Innodb_buffer_pool_pages_total
SQL语句如下：

在准备flush一个脏页时，如果相邻的数据页也是脏页，会把这个脏页一起flush，而且对这个新的脏页还可能有相邻的脏页导致连锁flush。
InnoDB使用 innodb_flush_neighbors 参数控制这个行为，值为1会产生上述连锁flush的情况，值为0则不会找相邻页。

找相邻页flush的机制虽然可以减少很多随机IO，但会增加一次flush时间，导致flush时的SQL语句执行时间变慢。

现在基本都使用的SSD这种IOPS比较高的硬盘，建议将 innodb_flush_neighbors 参数设为0，提高flush的速度。

flush会占用IO资源影响了正在执行的SQL语句，本来正常情况下执行很快的一条语句，突然耗时大大增加，造成业务抖动。要尽量避免这种情况，需要合理的设置 innodb_io_capacity 的值，并且多关注脏页比例，不要让脏页比例经常接近75%。

【极客时间】 mysql实战45讲：第12节

InnoDB关键特性之double write

# 脏页刷盘的风险

两次写的原理机制

　　1、解决问题

　　2、使用场景

　　3、doublewrite的工作流程

　　4、崩溃恢复

# doublewrite的副作用

　　1、监控doublewrite负载

　　2、关闭doublewrite场景

一、脏页刷盘风险

关于IO的最小单位：

　　1、数据库IO的最小单位是16K（MySQL默认，oracle是8K）

　　2、文件系统IO的最小单位是4K（也有1K的）

　　3、磁盘IO的最小单位是512字节

因此，存在IO写入导致page损坏的风险：

  

 

二、doublewrite：两次写

　　提高innodb的可靠性，用来解决部分写失败(partial page write页断裂)。

1、Double write解决了什么问题

　　一个数据页的大小是16K，假设在把内存中的脏页写到数据库的时候，写了2K突然掉电，也就是说前2K数据是新的，后14K是旧的，那么磁盘数据库这个数据页就是不完整的，是一个坏掉的数据页。redo只能加上旧、校检完整的数据页恢复一个脏块，不能修复坏掉的数据页，所以这个数据就丢失了，可能会造成数据不一致，所以需要double write。

2、使用情景

　　当数据库正在从内存想磁盘写一个数据页是，数据库宕机，从而导致这个页只写了部分数据，这就是部分写失效，它会导致数据丢失。这时是无法通过重做日志恢复的，因为重做日志记录的是对页的物理修改，如果页本身已经损坏，重做日志也无能为力。

3、double write工作流程

 

　　doublewrite由两部分组成，一部分为内存中的doublewrite buffer，其大小为2MB，另一部分是磁盘上共享表空间(ibdata x)中连续的128个页，即2个区(extent)，大小也是2M。

　　1、当一系列机制触发数据缓冲池中的脏页刷新时，并不直接写入磁盘数据文件中，而是先拷贝至内存中的doublewrite buffer中；

　　2、接着从两次写缓冲区分两次写入磁盘共享表空间中(连续存储，顺序写，性能很高)，每次写1MB；

　　3、待第二步完成后，再将doublewrite buffer中的脏页数据写入实际的各个表空间文件(离散写)；(脏页数据固化后，即进行标记对应doublewrite数据可覆盖)

4、doublewrite的崩溃恢复

　　如果操作系统在将页写入磁盘的过程中发生崩溃，在恢复过程中，innodb存储引擎可以从共享表空间的doublewrite中找到该页的一个最近的副本，将其复制到表空间文件，再应用redo log，就完成了恢复过程。

　　因为有副本所以也不担心表空间中数据页是否损坏。

Q：为什么log write不需要doublewrite的支持？

A：

　　因为redolog写入的单位就是512字节，也就是磁盘IO的最小单位，所以无所谓数据损坏。

 

三、doublewrite的副作用

1、double write带来的写负载

　　1、double write是一个buffer, 但其实它是开在物理文件上的一个buffer, 其实也就是file, 所以它会导致系统有更多的fsync操作, 而硬盘的fsync性能是很慢的, 所以它会降低mysql的整体性能。

　　2、但是，doublewrite buffer写入磁盘共享表空间这个过程是连续存储，是顺序写，性能非常高，(约占写的%10)，牺牲一点写性能来保证数据页的完整还是很有必要的。

2、监控double write工作负载

mysql> show global status like \'%dblwr%\';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Innodb_dblwr_pages_written | 7     |
| Innodb_dblwr_writes        | 3     |
+----------------------------+-------+
2 rows in set (0.00 sec)

　　关注点：Innodb_dblwr_pages_written / Innodb_dblwr_writes

　　开启doublewrite后，每次脏页刷新必须要先写doublewrite，而doublewrite存在于磁盘上的是两个连续的区，每个区由连续的页组成，一般情况下一个区最多有64个页，所以一次IO写入应该可以最多写64个页。

　　而根据以上系统Innodb_dblwr_pages_written与Innodb_dblwr_writes的比例来看，大概在3左右，远远还没到64(如果约等于64，那么说明系统的写压力非常大，有大量的脏页要往磁盘上写)，所以从这个角度也可以看出，系统写入压力并不高。

3、关闭double write适合的场景

　　1、海量DML

　　2、不惧怕数据损坏和丢失

　　3、系统写负载成为主要负载

mysql> show variables like \'%double%\';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| innodb_doublewrite | ON    |
+--------------------+-------+
1 row in set (0.04 sec)

　　作为InnoDB的一个关键特性，doublewrite功能默认是开启的，但是在上述特殊的一些场景也可以视情况关闭，来提高数据库写性能。静态参数，配置文件修改，重启数据库。

4、为什么没有把double write里面的数据写到data page里面呢？

　　1、double write里面的数据是连续的，如果直接写到data page里面，而data page的页又是离散的，写入会很慢。

　　2、double write里面的数据没有办法被及时的覆盖掉，导致double write的压力很大；短时间内可能会出现double write溢出的情况。