文章目录
- 场景描述
- 重做日志(redo log)
- 归档日志(binlog)
- 两阶段提交
- 总结
- 附加:为什么我的 MySQL 会“抖”一下?
场景描述
MySQL 可以恢复到半个月内任意一秒的状态,惊叹的同时,你心中是不是不免也会好奇,这是怎样做到的呢?
- 一条SQL更新语句是如何执行的?首先,可以确定的说,上篇笔记查询语句的那一套流程,更新语句也是
同样会走一遍
。就是:连接器 -> 分析器 -> 优化器 -> 执行器 -> 存储引擎
- 与查询流程不一样的是,更新流程还涉及两个重要的日志模块,
redo log(重做日志)和 binlog(归档日志)
。
重做日志(redo log)
- MySQL 里经常说到的 WAL 技术,WAL 的全称是
Write-Ahead Logging
,它的关键点就是先写日志,再写磁盘
,因为每次更新都写磁盘速度太慢了。 - 具体来说,当有一条记录需要更新的时候,InnoDB 引擎就会
先把记录写到 redo log 里面
,并更新内存,这个时候更新就算完成了。同时,InnoDB 引擎会在适当的时候,将这个操作记录更新到磁盘里面,而这个更新往往是在系统比较空闲的时候做。 - 有了 redo log,InnoDB 就可以保证即使数据库发生异常重启,之前提交的记录都不会丢失,这个能力称为
crash-safe
。 - 要理解 crash-safe 这个概念,可以想想赊账记录的例子。只要赊账记录记在了粉板上或写在了账本上,之后即使掌柜忘记了,比如突然停业几天,恢复生意后依然
可以通过账本和粉板上的数据明确赊账账目
。
归档日志(binlog)
MySQL 整体来看,其实就有两块:一块是 Server 层,它主要做的是 MySQL 功能层面的事情;还有一块是引擎层,负责存储相关的具体事宜。上面我们聊到的
redo log
是InnoDB 引擎特有的日志
,而Server 层
也有自己的日志,称为binlog(归档日志)
。
- 为什么会有两份日志呢?
- 其实最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM,但是 MyISAM 没有 crash-safe 的能力,binlog 日志只能用于归档。而 InnoDB 是另一个公司以插件形式引入 MySQL 的,既然只依靠 binlog 是没有 crash-safe 能力的,所以 InnoDB 使用另外一套日志系统——也就是
redo log 来实现 crash-safe 能力
。
- 这两种日志有以下三点不同:
- redo log 是 InnoDB 引擎
特有的
;binlog 是 MySQL 的 Server 层实现的,所有引擎
都可以使用。 - redo log 是
物理日志
,记录的是“在某个数据页上做了什么修改”;binlog 是逻辑日志
,记录的是这个语句的原始逻辑,比如“给 ID=2 这一行的 c 字段加 1 ”。 - redo log 是循环写的,
空间固定
会用完;binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个,并不会覆盖以前的日志
。
- 有了对这两个日志的概念性理解,我们再来看执行器和 InnoDB 引擎在执行这个简单的 update 语句时的内部流程。
- 执行器先找引擎取 ID=2 这一行。ID 是主键,引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中,就直接返回给执行器;否则,需要先从磁盘读入内存,然后再返回。
- 执行器拿到引擎给的行数据,把这个值加上 1,比如原来是 N,现在就是 N+1,得到新的一行数据,再调用引擎接口写入这行新数据。
- 引擎将这行新数据更新到内存中,同时将这个更新操作记录到 redo log 里面,此时 redo log 处于 prepare 状态。然后告知执行器执行完成了,随时可以提交事务。
- 执行器生成这个操作的 binlog,并把 binlog 写入磁盘。
- 执行器调用引擎的提交事务接口,引擎把刚刚写入的 redo log 改成提交(commit)状态,更新完成。
- 这里给出这个 update 语句的执行流程图,图中浅色框表示是在 InnoDB 内部执行的,深色框表示是在执行器中执行的。
- 最后三步看上去有点“绕”,将 redo log 的写入拆成了两个步骤:prepare 和 commit,这就是“
两阶段提交
”。
两阶段提交
为什么必须有“两阶段提交”呢?这是为了让两份日志之间的逻辑一致。要说明这个问题,我们得从文章开头的那个问题说起:怎样让数据库恢复到半个月内任意一秒的状态?
- binlog 会记录所有的逻辑操作,并且是采用“追加写”的形式。如果你的 DBA 承诺说半个月内可以恢复,那么备份系统中一定会保存最近半个月的所有 binlog,同时系统会定期做整库备份。这里的“定期”取决于系统的重要性,可以是一天一备,也可以是一周一备。
- 当需要
恢复到指定的某一秒
时,比如某天下午两点发现中午十二点有一次误删表,需要找回数据,那你可以这么做:
- 首先,找到
最近的一次全量备份
,如果你运气好,可能就是昨天晚上的一个备份,从这个备份恢复到临时库; - 然后,从备份的时间点开始,将备份的 binlog 依次取出来,重放到中午误删表之前的那个时刻。
为什么日志需要“两阶段提交”,这里可以用反证法来解释。
- 先写 redo log 后写 binlog。假设在 redo log 写完,binlog 还没有写完的时候,MySQL 进程异常重启。由于我们前面说过的,redo log 写完之后,系统即使崩溃,仍然能够把数据恢复回来,所以恢复后这一行 c 的值是 1。但是由于 binlog 没写完就 crash 了,这时候 binlog 里面就没有记录这个语句。因此,之后备份日志的时候,存起来的 binlog 里面就没有这条语句。然后你会发现,如果需要用这个 binlog 来恢复临时库的话,由于这个语句的 binlog 丢失,这个临时库就会少了这一次更新,恢复出来的这一行 c 的值就是 0,与原库的值不同。
- 先写 binlog 后写 redo log。如果在 binlog 写完之后 crash,由于 redo log 还没写,崩溃恢复以后这个事务无效,所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1”这个日志。所以,在之后用 binlog 来恢复的时候就多了一个事务出来,恢复出来的这一行 c 的值就是 1,与原库的值不同。
- 可以看到,如果不使用“两阶段提交”,那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。
总结
对比 | redo log | binlog |
日志所属 | InnoDB 引擎 | MySQL 的 Server 层实现的, |
内容 |
|
|
空间 | 循环写入, | 追加写入,写到一定大小后会切换到下一个,并 |
作用 | 保证 | 主要用来 |
附加:为什么我的 MySQL 会“抖”一下?
平时的工作中,不知道你有没有遇到过这样的场景,一条 SQL 语句,正常执行的时候特别快,但是有时也不知道怎么回事,它就会变得特别慢,并且这样的场景很难复现,它不只随机,而且持续时间还很短。
- 当内存数据页跟磁盘数据页内容不一致的时候,我们称这个内存页为“
脏页
”。内存数据写入到磁盘后,内存和磁盘上的数据页的内容就一致了,称为“干净页”。 - MySQL 抖一下就是在刷脏页, 刷脏页的四个场景:
-
redo log 满了
,这时候系统会停止所有更新操作,把 checkpoint 往前推进,redo log 留出空间可以继续写。 -
内存满了
,当需要新的内存页,而内存不够用的时候,就要淘汰一些数据页,空出内存给别的数据页使用。如果淘汰的是“脏页”,就要先将脏页写到磁盘。 - MySQL
空闲
的时候 - MySQL
正常关闭
的时候
笔记来源于《极客时间:MySQL实战45讲:日志系统:一条SQL更新语句是如何执行的?》