MySQL redo log及recover过程浅析

写在前面：作者水平有限，欢迎不吝赐教，一切以最新源码为准。

InnoDB redo log

首先介绍下Innodb redo log是什么，为什么需要记录redo log，以及redo log的作用都有哪些。这些作为常识，只是为了本文完整。   InnoDB有buffer pool（简称bp）。bp是数据库页面的缓存，对InnoDB的任何修改操作都会首先在bp的page上进行，然后这样的页面将被标记为dirty并被放到专门的flush list上，后续将由master thread或专门的刷脏线程阶段性的将这些页面写入磁盘（disk or ssd）。这样的好处是避免每次写操作都操作磁盘导致大量的随机IO，阶段性的刷脏可以将多次对页面的修改merge成一次IO操作，同时异步写入也降低了访问的时延。然而，如果在dirty page还未刷入磁盘时，server非正常关闭，这些修改操作将会丢失，如果写入操作正在进行，甚至会由于损坏数据文件导致数据库不可用。为了避免上述问题的发生，Innodb将所有对页面的修改操作写入一个专门的文件，并在数据库启动时从此文件进行恢复操作，这个文件就是redo log file。这样的技术推迟了bp页面的刷新，从而提升了数据库的吞吐，有效的降低了访问时延。带来的问题是额外的写redo log操作的开销（顺序IO，当然很快），以及数据库启动时恢复操作所需的时间。   接下来将结合MySQL 5.6的代码看下Log文件的结构、生成过程以及数据库启动时的恢复流程。   Log文件结构 Redo log文件包含一组log files，其会被循环使用。Redo log文件的大小和数目可以通过特定的参数设置，详见：innodb_log_file_size 和 innodb_log_files_in_group 。每个log文件有一个文件头，其代码在"storage/innobase/include/log0log.h"中，我们看下log文件头都记录了哪些信息：

MySQL redo log及recover过程浅析,布布扣,bubuko.com