目录
一、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还是使用方法加快恢复：
哈希表
1919
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
