目录
一、redo日志刷盘机制（时机）
1、log buffer 空间不足时
2、事务提交
3、后台线程
4、正常关闭服务器
5、checkpoint时
二、数据目录中的redo日志文件
三、redo日志文件格式
log buffer与磁盘交互的最小单位——block
文件格式
四、Log Sequeue Number（了解）
五、崩溃恢复
1、确定恢复的起点
2、确定恢复的重点
3、开始恢复
用什么方法恢复？
哈希表
同时跳过已经刷新到磁盘的页面
一、redo日志刷盘机制（时机）
1、log buffer 空间不足时
log buffer的大小是有限制的，默认是16MB，当log buffer的空间已经占了一半左右，就会出发吧这些日志刷新到磁盘上。
2、事务提交
为了保证事务的持久性，当事务提交之后，就会刷新log buffer 中的部分block进入磁盘。
3、后台线程
后台线程每秒都会刷新一次log buffer 中block中的redo日志到磁盘
4、正常关闭服务器
正常关闭服务器就会刷新log buffer 中的redo日志到磁盘
5、checkpoint时
checkpoint其实就是buffer pool中的脏页刷入磁盘，刷入磁盘之前一定要把对应的redo日志刷入磁盘
二、数据目录中的redo日志文件
前面的文章详细的介绍过，操作系统是用文件来管理mysql的，磁盘中的数据目录用来存储数据文件，redo日志文件就存储在数据目录的名为ib_logfile0和ib_logfile1的文件，log buffer 中的日志默认就是刷入到磁盘的这两个文件中。
注意：根据命名可以看出，这个redo文件并不只有一个，而是以组的形式存在，当0写满就写入1中，1写满就写入2，如果写到最后一个文件，就重新转到0去写，也就是把0的文件覆盖掉。这也就设计了上面的只是checkpoint，什么样的redo日志可以被覆盖。（先说结论，buffer log中的脏页产生的redo 日志，并且这个脏页已经被刷入磁盘，也就意味着此redo 日志已经没有用了，就可以被覆盖了）
三、redo日志文件格式
注意上一篇文章介绍的是redo日志的格式和log buffer的格式。现在介绍的磁盘中的redo日志文件格式。
log buffer与磁盘交互的最小单位——block
log buffer本质就是一片连续的内存空间，被划分成了若干个512字节大小的block。将log buffer 中的redo日志刷新到磁盘本质就是把block的镜像写入日志文件中。
文件格式
由两个部分组成：
~前2048个字节（前4个block）用来存储一些管理信息的。
~从第2048字节往后是用来存储log buffer中的block镜像的。
~注意：上面说过的覆盖循环就是从每个日志文件的第2048字节开始算。
四、Log Sequeue Number（了解）
简称lsn，日志序列号。为什么要介绍他呢，他又有什么作用？
首先我们要知道虽然redo日志小，但是一个语句可以产生很多mtr，而mtr会产生很多redo日志，所以redo日志的数量不断快速递增，那我们怎么确定把redo日志写在log buffer的什么位置呢，lsn被设计出来了。
lsn初始值8704（设计就是这么设计的），当log buffer中一条日志也没写入的时候lsn的值就是8704。
lsn随着日志插入增加，lsn的增长量是的计算（需要计算block的log block header和log block trailer）：
五、崩溃恢复
讲了这么多不知道大家发现没有，redo在服务器没有挂的时候完全就是累赘，浪费了很多时间和少量的空间。但是万一数据库挂了，那redo日志就是很厉害了，重启之后就可以根据redo日志将页面恢复到崩溃前的状态。那恢复的过程都发生了什么呢？
1、确定恢复的起点
上面没有介绍怎么确定哪些redo日志可以被覆盖，log buffer刷盘机制有一个就是脏页刷入之前，先将redo日志刷入磁盘，这些就没有必要刷入了，但是伴随着别的机制所以磁盘中可能存在脏页还没有刷入的redo日志，这些是有用的，不能被覆盖，而恢复就是从这个点之后进行顺序恢复，注意这个点之后的redo日志对应的脏页可能被刷入磁盘了，这点我们不能确定，不确定就全刷，mysql也有机制判断是否被刷入。
2、确定恢复的重点
终点我们想当然的觉得终点很容易确定，就是最后的block，但是计算机怎么确定是最后的block呢？
3、开始恢复
checkpoint_lsn就是上面说的那个点，这之前的脏页都被刷入到磁盘了，索引恢复后面的redo日志，这些日志放在block中。
顺序写入的，也要顺序恢复。
用什么方法恢复？
如果按照顺序依次恢复页没问题，但是mysql还是使用方法加快恢复：
哈希表
