2日志空间满_MySQL日志系统

MySQL日志系统

MySQL有两个重要的日志系统&＃xff0c;分别是 redo log (重做日志) 和 bin log (归档日志) 。

这两种日志有以下三点不同。

• redo log 是 InnoDB 引擎特有的&＃xff1b;binlog 是 MySQL 的 Server 层实现的&＃xff0c;所有引擎都可以使用。
• redo log 是物理日志&＃xff0c;记录的是“在某个数据页上做了什么修改”&＃xff1b;binlog 是逻辑日志&＃xff0c;记录的是这个语句的原始逻辑&＃xff0c;比如“给 ID&＃61;2 这一行的 c 字段加 1 ”。
• redo log 是循环写的&＃xff0c;空间固定会用完&＃xff1b;binlog 是可以追加写的。“追加写” 是指 binlog 文件写到一定大小后会切换到下一个&＃xff0c;并不会覆盖以前的日志。

1. redo log

为了理解这个日志&＃xff0c;可以举一个酒店掌柜的例子。说是有一个酒店掌柜&＃xff0c;他有一个粉板专门记录客人赊账的情况&＃xff0c;如果赊账的人不多&＃xff0c;那么他可以把顾客名和账目写在板上。但如果赊账的人多了&＃xff0c;粉板总会有记不下的时候&＃xff0c;这个时候掌柜一定还有一个专门记录赊账的账本。

如果有人要赊账或者还账的话&＃xff0c;掌柜一般有两种做法&＃xff1a;

• 一种做法是直接把账本翻出来&＃xff0c;把这次赊的账加上去或者扣除掉&＃xff1b;
• 另一种做法是先在粉板上记下这次的账&＃xff0c;等打烊以后再把账本翻出来核算。

在生意红火柜台很忙时&＃xff0c;掌柜一定会选择后者&＃xff0c;因为前者操作实在是太麻烦了。

同样&＃xff0c;在 MySQL 里也有这个问题&＃xff0c;如果每一次的更新操作都需要写进磁盘&＃xff0c;然后磁盘也要找到对应的那条记录&＃xff0c;然后再更新&＃xff0c;整个过程 IO 成本、查找成本都很高。为了解决这个问题&＃xff0c;MySQL 的设计者就用了类似酒店掌柜粉板的思路来提升更新效率。redo log 就相当于是粉板&＃xff0c;而 bin log 相当于是账本。

而粉板和账本配合的整个过程&＃xff0c;其实就是 MySQL 里经常说到的 WAL 技术&＃xff0c;WAL 的全称是 Write-Ahead Logging&＃xff0c;它的关键点就是先写日志&＃xff0c;再写磁盘&＃xff0c;也就是先写粉板&＃xff0c;等不忙的时候再写账本。

InnoDB 的 redo log 是固定大小的&＃xff0c;比如可以配置为一组 4 个文件&＃xff0c;每个文件的大小是 1GB&＃xff0c;那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写&＃xff0c;写到末尾就又回到开头循环写&＃xff0c;如下面这个图所示。

write pos 是当前记录的位置&＃xff0c;一边写一边后移&＃xff0c;写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置&＃xff0c;也是往后推移并且循环的&＃xff0c;擦除记录前要把记录更新到数据文件。

write pos 和 checkpoint 之间的是“粉板”上还空着的部分&＃xff0c;可以用来记录新的操作。如果 write pos 追上 checkpoint&＃xff0c;表示“粉板”满了&＃xff0c;这时候不能再执行新的更新&＃xff0c;得停下来先擦掉一些记录&＃xff0c;把 checkpoint 推进一下。

有了 redo log&＃xff0c;InnoDB 就可以保证即使数据库发生异常重启&＃xff0c;之前提交的记录都不会丢失&＃xff0c;这个能力称为 crash-safe。要理解 crash-safe 这个概念&＃xff0c;可以想想我们前面赊账记录的例子。只要赊账记录记在了粉板上或写在了账本上&＃xff0c;之后即使掌柜忘记了&＃xff0c;比如突然停业几天&＃xff0c;恢复生意后依然可以通过账本和粉板上的数据明确赊账账目。

2. bin log

假设我们要执行一下一条简单的语句&＃xff0c;我们来看执行器和 InnoDB 引擎在执行这个简单的 update 语句时的内部流程。

1. 执行器先找引擎取 ID&＃61;2 这一行。ID 是主键&＃xff0c;引擎直接用树搜索找到这一行。如果 ID&＃61;2 这一行所在的数据页本来就在内存中&＃xff0c;就直接返回给执行器&＃xff1b;否则&＃xff0c;需要先从磁盘读入内存&＃xff0c;然后再返回。
2. 执行器拿到引擎给的行数据&＃xff0c;把这个值加上 1&＃xff0c;比如原来是 N&＃xff0c;现在就是 N&＃43;1&＃xff0c;得到新的一行数据&＃xff0c;再调用引擎接口写入这行新数据。
3. 引擎将这行新数据更新到内存中&＃xff0c;同时将这个更新操作记录到 redo log 里面&＃xff0c;此时 redo log 处于 prepare 状态。然后告知执行器执行完成了&＃xff0c;随时可以提交事务。
4. 执行器生成这个操作的 bin log&＃xff0c;并把 bin log 写入磁盘。
5. 执行器调用引擎的提交事务接口&＃xff0c;引擎把刚刚写入的 redo log 改成提交&＃xff08;commit&＃xff09;状态&＃xff0c;更新完成。

这里需要关注的点是最后三步将写 redo log 和写 bin log 打包成一个事务&＃xff0c;要保证redo log 和 bin log 的日志是一样的。