InnoDB体系架构简介（后台线程、缓冲池、重做日志缓冲、Checkpoint机制）

最新推荐文章于 2022-06-24 16:52:26 发布

IT_10-

最新推荐文章于 2022-06-24 16:52:26 发布

阅读量344

点赞数

分类专栏： MySQL 文章标签：缓冲池 Checkpoint InnoDB体系架构

本文链接：https://blog.csdn.net/IT_10/article/details/97433558

版权

MySQL 专栏收录该内容

31 篇文章 2 订阅

订阅专栏

下图是一个简易的InnoDB存储引擎体系架构
在这里插入图片描述
InnoDB存储引擎有多个内存块，这些内存块组成了一个大的内存池，主要负责：

维护所有进程/线程需要访问的多个内部数据结构（MySQL是单进程多线程模式）
缓存磁盘上的数据，方便快速读取，同时在对磁盘文件的数据修改之前在内存池中缓存
重做日志（redo log）缓冲
…

后台线程的主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存的是最近的数据。以及将已修复的数据文件刷新到磁盘文件中，同时保证在数据库发生异常的情况下InnoDB能恢复到正常运行状态。

后台线程

Master Thread：主要负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性
IO Thread：InnoDB存储引擎中使用了大量的异步IO处理写IO请求，IO Thread主要负责这些IO请求的回调处理
Purge Thread：回收undo页（事务提交后，undolog页不再需要）

内存

缓冲池

InnoDB存储引擎是基于磁盘存储的，并将其中的记录安装页的方式进行管理（默认一页大小为16K，MySQL5.5以前，一页固定为16k，MySQL5.5以后，页大小为4KB, 8KB, 或者16KB，MySQL5.7.6还支持32KB和64KB）。由于CPU和磁盘速度不匹配的问题，采用缓冲池（也称为内存池）来提高数据库的性能。
在读操作时，首先将从磁盘读到的页存放到缓冲池中（这一过程称为将页“FIX”到缓冲池中），下次再读取相同的页是，首先判断该页是否在缓冲池中，若在，则命中，直接读取页，否则读取磁盘上的页。
在修改操作是，首先修改在缓冲池中的页，再以一定的机制（CheckPoint）刷新到磁盘上。

缓冲池通过innodb_buffer_pool_size来设置，下图显示了MySQL5.6中默认缓冲池大小为128M。
在这里插入图片描述

缓冲池存储的数据对象包含如下图（内存区域图，左边两个不包含在缓冲池中）：
在这里插入图片描述

LRU

缓冲池是一个很大的内存区域，数据库中使用LRU（Latest Recent Used 最近最少使用）算法来进行管理。最频繁使用的页在LRU列表的前端。当缓冲池不能存放读到的新数据也时，将首先释放LRU列表尾部的页。

重做日志缓冲

上图显示了内存中除缓冲池之外的重做日志缓冲。重做日志即innodb存储引擎产生的日志，默认在mysql/data目录下面有两个文件ib_logfile0和ib_logfile1。当MySQL的实例和介质失败的时候，Innodb存储引擎就会使用重做日志文件进行恢复，保证数据库的完整性。

InnoDB存储引擎首先将重做日志信息放入这个缓冲区，然后按一定的频率将其刷新到重做日志文件。该缓冲区不会设置得很大，因为一般每一秒刷新一次到日志文件中。

一般会在一下两种情况刷新重做日志缓冲到重做日志磁盘文件中：

主线程每一秒刷新一次重做日志缓冲到重做日志磁盘文件中（同步fsync方式）
每个事务提交时由innodb_flush_log_at_trx_commit参数控制，其值取0表示事务提交时不触发写磁盘，而是等待主线程每秒的刷新操作，其值取1（默认值）表示同步写磁盘，其值取2表示异步写磁盘，即不能保证commit时一定会刷新重做日志缓冲到重做日志磁盘文件中，只是有这个动作发生

下图显示MySQL5.6下该缓冲区默认为8M：
在这里插入图片描述

额外的内存池

InnoDB在对一些数据结构本身的内存分配时，需要从额外的内存池中进行申请。例如缓冲池中的中的一些对象记录了锁、等待、LUR等消息，这些对象需要从额外的内存池中申请内存。

Checkpoint

缓冲池中的数据刷新到磁盘上并不是每次缓冲池中的页更新时触发的，而是通过Checkpoint机制。

如果重做日志可以无限地增大，同时缓冲池也足够大，那么是不需要将缓冲池中页的新版本刷新回磁盘。因为当发生宕机时，完全可以通过重做日志来恢复整个数据库系统中的数据到宕机发生的时刻。

但是这需要两个前提条件：

缓冲池可以缓存数据库中所有的数据
重做日志可以无限增大

第一个前提对于生成环境下的数据库难以得到保障，第二个前提成本高，且不利于运维。即使满足这两个前提条件，宕机后的数据库恢复也是非常耗时的。

因此检查的（Checkpoint）机制目的解决如下问题：

缩短数据库恢复时间
当缓冲池不够用时，根据LRU，将脏页刷新到磁盘上
从做日志不可用时，刷新脏页

当数据库发生宕机时，数据库只需将Checkpoint后的重做日志进行恢复。重做日志可以被重用的部分是指这些日志已经不再需要，即数据库宕机时，数据库恢复操作不需要这部分的重做日志，因此这部分就可以被覆盖重用。如果重做日志还需要使用，那么必须强制Checkpoint，将缓冲池中的页至少刷新到当前重做日志的位置。