MySQL-脏页的刷新机制

2020-07-17  本文已影响0人  ging_efcf
MySQL内存结构-缓冲区

MySQL的缓冲区中有数据页,索引页,插入缓冲等等,这个角度是从页的功能来分类的。本小节从另一个视角关注这些页,如果从 是否被修改过(和磁盘不一致) 这个角度来区分这些页,那么页可以被分为干净的页和脏页。

本小节主要关注脏页刷新到磁盘的机制,首先需要了解缓冲区的内存管理细节。

内存管理机制简述

缓冲区中包含这三大类列表。分别为:LRUList、FreeList、FlushList。

在数据库刚启动时,LRUlist中并没有数据页,空闲页都存放在FreeList中,当需要读取某个页时,会从free列表中获取一个空闲页,读入数据后,放入LRU列表中;如果free中没有空闲页了,那么根据LRU算法淘汰Lru列表中末位的页。

当LRU中的页被修改后,页就变成了脏页,这个页也会被加入Flush列表中。注意:这时这个页既在LRU列表中,又在Flush列表中。

总结:LRUList和FreeList用来管理页的可用性;Flush列表用来管理脏页的刷新

脏页的刷新机制-checkpoint机制
数据修改和读取只依赖缓冲区行不行?

如果数据修改和读取只依赖内存的缓冲区,那么一旦数据库宕机,内存中的数据都会丢失。所以MySQL使用之前讲过的redo log来实现异常重启的数据恢复,redolog相关介绍可以看篇文章:MySQL-redo log 和 binlog

简单来说,就是在更新缓冲区之前,先写入redo log,保证异常重启之后可以正常恢复缓冲区中的数据。

脏页为什么一定要刷新?

考虑这种情况

如果缓冲区无限大,可以装下所有的磁盘数据,redo log也可以无限大,那么就算异常重启,依靠redo log也可以恢复所有的更新。但现实中,首先,缓冲区依赖的内存空间不可能无限大,现实中有许多TB级别的数据库,但是目前还没有TB级别的内存;并且 redo log如果无限大或者有许多个文件,对运维和管理也是一个考验;最后,如果系统中有大量的修改操作,一旦宕机,恢复的时间也会非常长。

所以自然而然,我们就一定需要把内存中的脏页按照某种规则刷新到磁盘中,有了刷新这个操作,缓冲区的大小问题和redo log的大小问题都可以解决。

  1. 缓冲区不需要无限大了,因为可以持久化到磁盘
  2. redo log也不需要无限大了,因为一旦持久化到磁盘,redo log中对应的那部分数据就可以释放。
如何刷新呢?

上部分讨论的是脏页刷新到磁盘的必要性。那具体应该如何刷新呢?MySQL中,刷新的规则叫checkpoint机制。

在InnoDB存储引擎中,有两种checkpoint:

关于Fuzzy checkpoint,InnoDB存储引擎中可能包括如下几种:

刷新机制用更通俗易懂的角度来分析,上面的四种类型可以对应下面的

master thread中的定时刷新机制

1)InndoDB1.0.x版本之前的master thread。
每秒,会进行一次 dirty too much checkpoint。
每10秒

2)InndoDB1.2.x版本之前的master thread。
在1.0.x存在硬编码,每秒最多只会刷新100个脏页到磁盘中,这种规定其实限制了性能更高的SSD磁盘。

在1.0.x版本,可以使用innodb_io_capacity来表示磁盘io的吞吐量。刷新脏页的数量由innodb_io_capacity来控制,默认是200。

总结

了解脏页刷新机制以及相应的参数是很有必要的,当数据库系统某些性能问题时,要考虑是否是脏页刷新相关的配置参数不合理导致的。

根据实际业务,考虑缓冲区的大小,redo log的大小,最少空闲页,脏页比例,io吞吐量相关参数是否配置合理,根据优化相关参数,解决系统问题。

上一篇 下一篇

猜你喜欢

热点阅读