讲讲 MySQL 中的 WAL 策略和 CheckPoint 技术

客官°小女子只卖身不卖艺 2022-08-28 05:43 115阅读 0赞

![4eb60ac51f650e0ebd6216709d7ad73e.png][]

若有收获,请记得分享和转发哦

## InnoDB 体系架构 ##

在说 WAL 之前，有必要简单介绍下 InnoDB 存储引擎的体系架构，方便我们理解下文，并且 **redo log 也是 InnoDB 存储引擎所特有的**。

如下图，InnoDB 存储引擎由**内存池**和一些**后台线程**组成：

![0465be2d5520b08fefc55e427f068427.png][]

### 内存池 ###

先来解释下内存池。

首先，我们需要知道，InnoDB 存储引擎是基于磁盘存储的，并将其中的记录按照**页**的方式进行管理。因此可将其视为**基于磁盘的数据库系统**（Disk-base Database），在这样的系统中，众所周知，由于 CPU 速度与磁盘速度之间的不匹配，通常会使用**缓冲池**技术来提高数据库的整体性能。

![53d0f938b84d7d947292152c51fedaeb.png][]

### 后台线程 ###

后台线程其实最大的作用就是用来完成 “将从磁盘读到的页存放在缓冲池中” 以及 “将缓冲池中的数据以一定的频率刷新到磁盘上” 这俩个操作的，当然了，还有其他的作用。以下是《MySQL 技术内幕：InnoDB 存储引擎 - 第 2 版》对于后台线程的描述：

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

另外，**InnoDB 存储引擎是多线程的模型**，也就是说它拥有多个不同的后台线程，负责处理不同的任务。这里简单列举下几种不同的后台线程：

![83a7d0b7d50991d789f3058db868893e.png][]

redo log 与 WAL 策略

![764d05078c9e2561cb3678f963865843.png][]

![b9910acdcdb035625da5e646ac1c0b87.png][]

![ad2c5ec8238ad0f154837eadab99f34c.png][]

InnoDB 存储引擎会先写 redo log file 0，当 file 0 被写满的时候，会切换至 redo log file 1，当 file 1 也被写满时，会切换到 redo log file 2 中，而当 file 2 也被写满时，会再切换到  file 0 中。

可以看出，redo log file 的大小设置对于 InnoDB 存储引擎的性能有着非常大的影响：

*  redo log file 不能设置得太大，如果设置得很大，在恢复时可能需要很长的时间
 *  redo log file 又不能设置得太小了，否则可能导致一个事务的日志需要多次切换重做日志文件

CheckPoint 技术

![bdce91c742d42979e3576d13646493f0.png][]

![db76e19284aef64ee535a65662060251.png][]

所谓 redo log 不可用就是所有的 redo log file 都写满了。但事实上，其实 redo log 中的数据并不是时时刻刻都是有用的，那些已经不再需要的部分就称为 ”可以被重用的部分“，即当数据库发生宕机时，数据库恢复操作不需要这部分的 redo log，因此这部分就可以被覆盖重用（或者说被擦除）。

举个例子来具体解释下：一组 4 个文件，每个文件的大小是 1GB，那么总共就有 4GB 的 redo log file 空间。write pos 是当前 redo log 记录的位置，随着不断地写入磁盘，write pos 也不断地往后移，就像我们上文说的，写到 file 3 末尾后就回到 file 0 开头。CheckPoint 是当前要擦除的位置（将 Checkpoint 之前的页刷新回磁盘），也是往后推移并且循环的：

![a923b900d6ea21da1c55a390b9d42256.png][]

![febd1af3c32869e7d34d71c89f8539c2.png][]

## 有了 bin log 为什么还需要 redo log？ ##

前文我们讲过，MySQL 架构可以分成俩层，一层是 Server 层，它主要做的是 MySQL 功能层面的事情；另一层就是存储引擎，负责存储与提取相关的具体事宜。

redo log 是 InnoDB 引擎特有的日志，而 Server 层也有自己的日志，包括错误日志（error log）、二进制日志（binlog）、慢查询日志（slow query log）、查询日志（log）。

![5b7dd699ff382120aa2bcf5b0f892b6e.png][]

[4eb60ac51f650e0ebd6216709d7ad73e.png]: /images/20220828/aa05f8fb84f84f0e8d5ad3c6b4269b09.png
[0465be2d5520b08fefc55e427f068427.png]: /images/20220828/fe444b3b0a584cc890eb9c0f426e68e4.png
[53d0f938b84d7d947292152c51fedaeb.png]: /images/20220828/06ad21e1a1f843ff95dc20b201f1238c.png
[83a7d0b7d50991d789f3058db868893e.png]: /images/20220828/6cae3951f3494429b748c2e01b58a6d7.png
[764d05078c9e2561cb3678f963865843.png]: /images/20220828/df9ca05a5e08489bb2c29ce0b477dfbb.png
[b9910acdcdb035625da5e646ac1c0b87.png]: /images/20220828/a3228430f0b248279f68d54851a50a0e.png
[ad2c5ec8238ad0f154837eadab99f34c.png]: /images/20220828/9cc06f6e432643fb8624f3a23ea55aae.png
[bdce91c742d42979e3576d13646493f0.png]: /images/20220828/247785a4a75b46a89b194fdf224bcb97.png
[db76e19284aef64ee535a65662060251.png]: /images/20220828/a557abb753f54e0bb5a5b0cd6effb7e6.png
[a923b900d6ea21da1c55a390b9d42256.png]: /images/20220828/ac79aae9291543ee98f82c78697cf7a0.png
[febd1af3c32869e7d34d71c89f8539c2.png]: /images/20220828/0856b3f9679846cebf6329bcbac36867.png
[5b7dd699ff382120aa2bcf5b0f892b6e.png]: /images/20220828/32fb8231cceb45118fa160590d59575f.png