MySQL 崩溃恢复过程分析

MySQL 崩溃恢复过程分析

天有不测风云，数据库有旦夕祸福。

前面写 Redo 日志的文章介绍过，数据库正常运行时，Redo 日志就是个累赘。

现在，终于到了 Redo 日志扬眉吐气，大显身手的时候了。

本文我们一起来看看，MySQL 在崩溃恢复过程中都干了哪些事情，Redo 日志又是怎么大显身手的。

本文介绍的崩溃恢复过程，包含 server 层和 InnoDB，不涉及其它存储引擎，内容基于 MySQL 8.0.29 源码。

正文

1、概述

MySQL 崩溃也是一次关闭过程，只是比正常关闭着急了一些。

正常关闭时，MySQL 会做一系列收尾工作，例如：清理 undo 日志、合并 change buffer 缓冲区等操作。

具体会进行哪些收尾工作，取决于系统变量 innodb_fast_shutdown 的配置。

崩溃直接就是戛然而止，撂挑子不干了，还没来得及进行的那些收尾工作怎么办？

那就只能等待下次启动的时候再干了，这就是本文要介绍的崩溃恢复过程。

2、读取两次写页面

MySQL 一旦崩溃，Redo 日志就要去拯救世界了（MySQL 就是它的世界），Redo 日志拯救世界的方式就是把还没来得及刷盘的脏页恢复到崩溃之前那一刻的状态。

虽然 Redo 日志能够用来恢复数据页，但这是有前提条件的：数据页必须完好无损的状态。

本文我们把系统表空间、独立表空间、undo 表空间中的页统称为数据页。

如果数据页刚写了一半，MySQL 就戛然而止，这个数据页就损坏了，面对这种情况，Redo 日志也是巧妇难为无米之炊。

Redo 日志拯救世界之路就要因为这个问题停滞不前吗？

那显示是不能的，这就该轮到两次写上场了。

两次写​的官方名字是 double write​，它包含内存缓冲区​和 dblwr 文件两个部分，InnoDB 脏页刷盘前，都会先把脏页写入内存缓冲区，再写入 dblwr 文件，成功之后才会把脏页刷盘。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。