一丶什么是redo
innodb是以也为单位来管理存储空间的，增删改查的本质都是在访问页面，在innodb真正访问页面之前，需要将其加载到内存中的buffer pool中之后才可以访问，但是在聊事务的时候，事务具备持久性,如果只在内存中修改了页面，而在事务提交后发生了系统崩溃，导致内存数据丢失，就会发生提交事务所作的更改还没来得及持久化到磁盘。
那么如何保证到提交的事务，所作更改一定持久化到磁盘了昵？
最简单粗暴的固然是，每次事务提交都将其所作更改持久化到磁盘。这种操作又存在如下问题：
刷新一个完整的页面，十分浪费IO，有时候事务所作的更改只是一个小小的字节，但由于innodb是以页为单位的对磁盘进行io操作的，这时候需要把一个完整的页刷新到磁盘，为了一个字节刷新16k的内容，是不划算的
随机io刷新缓慢，一个事务包含多个数据库操作，一个数据库操作包含对多个页面的修改，比如修改的数据不在相邻的页，存在多个不同的索引B+树需要维护，这时候需要刷新这些零散的页面，进行大量的随机IO
InnoDB是如何实现事务提交的持久化——记录下更改的内容
在事务提交的时候只记录下，事务做了什么变更到redolog，中这样即使系统崩溃了，重启之后只需要按照redo log上的内容进行恢复，重新更新数据页，那么该事务还是具备持久性的，这便是重做日志——redo log。使用redo log的好处：
redo log占用空间小：在存储事务所作变更的时候，需要存储变更数据页所在的表空间，页号，偏移量以及需要更新的值时，需要的空间很少。
redo log是顺序写入磁盘的，在执行事务的过程中，在执行每一条语句的时候，就可能产生若干条redo log，这些日志都是按照产生的顺序写入磁盘的，也就是使用顺序io
二丶redo log 日志的格式
type：redo log日志的类型
space id：表空间号
page number：页号
data：日志内容
通常一个执行语句是会修改到许多页面的，比如一个表具备多个索引，进行更新的时候需要维护聚簇索引和各种非聚簇索引，表中存在多少个索引就会可能会更新到多少个B+树，针对一颗B+树来说，极可能更新到叶子节点，也可能更新到非叶子节点，甚至还伴随着创建新页面，页面分裂，在内节点页面添加目录项等等操作。
理论上说red log只需要记录下insert 语句对页面所有的修改即可，但是插入数据到一个页面，也伴随着对这个页面的File Header,Pahe Header等等信息的修改
可见，将一条记录插入到一个页面，需要更改的地方很多，为此redo log定义了许多不同的日志格式，从物理层面来说：redo log指明了需要在哪一个表空间，的哪一个页进行什么修改内容，从逻辑层面来说：redo log在mysql崩溃恢复后，并不能直接使用这些日志记录的内容，而是需要调用一些函数，将页面进行恢复
三丶Mini-Transaction
mysql把底层页面的一次原子访问过程称为一个Mini-Transaction（MTR）（比如向B+树中插入一条记录的过程算作一个MTR，即使这个sql涉及到多个B+树）一个MTR可以包含一组redo log，在进行崩溃恢复的时候需要把这一组MTR看作是一个不可分割的整体（B+树中插入一条记录，可能涉及到叶子节点，非叶子点的改动，不能说只新增了叶子节点，但是没用更新非叶子节点，需要保证这个过程的原子性）
一个事务可以包含多个语句，一个语句可以包含多个MTR，一个MTR可以包含多个redo log日志，那么innodb是如何确认多个redo log属于一个MTR的昵
多个redo log以最后一条类型为MLOG_MULTI_REC_END类型的日志结尾，那么视为前面的redo log为同一MTR中的日志。系统在进行崩溃恢复的时候，只有解析到MLOG_MULTI_REC_END类型的日志的时候，才认为解析到了一组完整的redo log日志，才会进行恢复。
有些需要保证原子性的操作，只会产生一条redo log，比如更新Max Row ID(innodb在用户没用指定主键的时候，将此值存储在页中，没增大到256的整数倍的时候，才会更新写回磁盘)，这个时候会将其的type字段的第一个比特置为1，表示这个单个redo log 便是一个原子性操作，而不是加上一个MLOG_MULTI_REC_END类型的日志。
四丶redo log日志写入过程
1.redo log block
innodb 将通过MTR生成的redo log放在大小为512字节的block中，其中存储redo log的部分只有log block body其余的两部分存储一些统计信息
log block header
log_block_hdr_no:每一个block 具备一个大于0的唯一编号，此属性便是记录编号值
log_block_hdr_data_len:记录当前lock block使用了多少字节（从12开始，因为lock block header占用了12字节），随着越来越多的日志写入block最后最大为512字节
log_block_first_rec_group:一个MTR包含多个日志，这个字段记录该block中第一个MTR生成redo log日志记录组的偏移量。
log_block_checkpoint_no：表示checkpoint的序号
log block trailer
log_block_check_sum：表示block检验和，用于正确性校验
2.redo log buffer
为了解决磁盘写入过慢的问题，innodb采用了redo log buffer，写入redo log不会直接写入磁盘，而是在服务启动的时候申请一片连续的内存空间，用作缓冲redo log的写入
innodb_log_buffer_size可以指定其大小，默认16mb
3.redo log写入log buffer
innodb保存了一个buf_free的全局变量用于记录log buffer中空闲位置的偏移量，让后续redo log的写入从buf_free的位置开始写。
不同的事务是可以并发运行的，并发的写入redo log buffer中，每当一个MTR执行完成时，伴随着该MTR生成的redo log被写入到log buffer中，多个不同事务的MTR可能时交替写如到log buffer中的
五丶redo log持久化
1.redo log buffer中的内容何时持久化到磁盘
MTR运行过程中产生的一组redo log会在MTR结束的时候被复制到log buffer中，但是何时落盘昵？
log buffer 空间不足
如果写入log buffer的redo log日志量已经占满log buffer的一半时，会进行刷盘
事务提交时
之所以使用redo log，是由于其占用内存小，可以顺序IO写回磁盘，为了保证事务的持久性，需要把修改页面对应的redo log刷新到磁盘，这样系统崩溃时也可以将已提交的事务使用redo log进行恢复
将某个脏页刷新到磁盘前
将buffer pool中的脏页刷盘的时候，会保证将其之前产生的redo log刷盘
后台线程，每秒一次的频率将redo log buffer中刷盘
正常关闭mysql服务器时
做checkpoint时
2.redo log 日志文件组
mysql的数据目录下默认有两个redo log日志文件，默认名称为ib_logfile0和ib_logfile1,log buffer中的内容便是刷新到着两个文件中。可以通过以下系统变量进行设置
innodb_log_group_home_dir：指定redo log日志文件所在目录
innodb_log_file_size:指定每一个redo log日志文件大小
innodb_log_file_in_group:指定redo log日志文件的个数
日志文件不知一个，而是以一个日志文件组的形式出现的，都是ib_logfile数字格式的名称，在持久化redo log的时候，首先从ib_logfile0开始写，然后写ib_logfile1直到写到最后一个文件，这时候需要做checkpoint，后继续从ib_logfile0写，从头开始写，写到末尾就又回到开头循环写，如下图
3.redo log日志文件格式
每一个redo log文件前2048个字节（四个redo log block大小）用来存储管理信息，后续的位置存储log buffer中redo log block镜像
前2048字节分为四个block，如上图
log file header 描述该日志的一些整体属性
checkpoint1 & checkpoint2，格式相同
log_checkpoint_no：服务器执行checkpoint的编号，每执行一次checkpoint该值加1
log_checkpoint_lsn：服务器在结束checkpoint时对应的lsn值，系统崩溃时从该值开始
log_checkpoint_offset：log_checkpoint_lsn属性值，在redo日志文件组中的偏移量
log_checkpoint_log_buf_size：服务器在执行checkpoint操作时对应的log buffer大小
log_checkpoint_checksum：本block校验值，无需关心
4.LSN——log squence number记录当总共写入的redo 日志量
innodb的一个全局变量，用于记录当总共写入的redo 日志量，初始值为8704（未产生一条redo日志也是8704）。并不是记录刷到磁盘的redo log日志总量，而是写入到log buffer中的redo log日志量
每一组MTR生成的redo log都有唯一一个lsn值与之对应，其中lsn越小表示对应的redo log产生越早
5.flushed_to_disk_lsn记录刷新到磁盘中的redo日志量
redo log总是先写入到redo log buffer然后才会被刷新磁盘中的，所有需要有一个变量记录下一次从log buffer中刷盘的起始位置——buf_next_to_write
flushed_to_disk_lsn记录刷新到磁盘的redo log 日志量
当存在新的日志写入到log buffer的时候，首先lsn(log squence number记录当总共写入的redo 日志量)会增大，但是flushed_to_disk_lsn大小不变（因为没刷盘）随着log buffer中的内容刷新到磁盘，flushed_to_disk_lsn将随之增大，当flushed_to_disk_lsn = lsn的时候说明所有log buffer中的日志都刷新到了磁盘
6.buffer pool 中flush 链表中的lsn
MTR是对底层页面的一次原子访问，在访问过程中会产生一组不可以分割的redo log，在MTR结束的时候会把这一组redo log记录到log buffer中。除此之外在MTR结束的时候还需要：把MTR执行过程中修改的页面加入到Buffer pool中的flush链表中，毕竟刷新脏页到磁盘是buffer pool的任务。
当这个页面第一次被修改的时候就会将其对应的控制块插入到flush 链表头部，后续再次修改不会移动控制块，因为其已经在flush 链表中，所有说flush 链是按照页面第一次修改的时间进行排序的，在这个过程中会记录两个重要的属性到脏页的控制块中：
oldest_modification
第一次修改修改buffer pool某个缓冲页（先把页读到buffer pool的缓冲页，然后进行修改）时，记录下修改该页面MTR开始时对应的lsn(注意这个开始时)
newest_modification
每次修改页面，都会记录下修改该页面MTR结束时的lsn,该属性记录最近一次修改后对应的lsn
例如第一个MTR1修改了页A，在oldest_modification记录下开始时的lsn为8716，newest_modification记录下MTR1结束时的lsn
MTR2后续修改了页B和页C，页B，页C最开始不在flush链表中，背修改后加入到链表的头部，也就是说，越靠近头部，修改的时间就越晚，如下：
如果此时在flush链表中的页被修改，只需要更新newest_modification即可。flush链表按照第一次被更新时候的lsn排序，也就是按照oldest_modification进行排序，多次修改位于flush链表中的页只会更新其newest_modification
7.checkpoint
由于redo log日志文件文件是有限的，所有需要循环使用redolog 日志文件组中的文件。redo log存在的目的是系统崩溃后恢复脏页，如果对应的脏页已经刷新到磁盘中，那么即使系统崩溃，重启之后页不需要使用redo log恢复该页面看，对应的redo log日志也没存在的必要了，占用的磁盘空间可以进行重复使用，被其他redo log日志覆盖。那么如何判断哪些redo 日志占用的磁盘空间可以覆盖昵，其对应的脏页已经刷新到磁盘了昵？
innodb使用checkpoint_lsn记录可以被覆盖的redo log日志总量
假如页A已经被刷新到磁盘了，那么页A对应的控制块会从flush链表中移除，MTR1生成的日志可以被覆盖了，就进行一个增加checkpoint_lsn的操作，这个过程称作执行一次checkpoint(刷新脏页到磁盘和执行一次checkpoint是两回事，通常是不同线程上执行的，并不意味着每次刷新脏页的时候都会执行一次checkpoint)
执行一次checkpoint的操作可以分为两个步骤：
计算当前系统中可以覆盖的redo日志对应的lsn最大是多少
比如页A已经被刷盘了，此时flush链表的尾部便是页C，其oldest_modification=8916那么说明redo log日志对应lsn值小于8916的均可被覆盖，checkpoint_lsn的值会被设置为8916
将checkpoint_lsn和对应的日志文件组偏移量和这次checkpoint的编号写入到日志文件的管理信息中（checkpoint1，checkpoint2）
innodb使用checkpoint_no记录当前系统执行了多少次checkpoint，根据lsn值计算除redo log日志的偏移量（lsn初始值为8704，redo日志文件组偏移量为2048）计算得到checkpoint_offset,将checkpoint_no,checkpoint_lsn,checkpoint_offeset写回到redo log日志文件组管理信息中，关于checkpoint的信息，当checkpoint_no为偶数的时候会写回到checkpoint1，反之写入到checkpoint2中。
8.控制事务提交时刷新redo log日志的选项——innodb_flush_log_at_trx_commit
如果每次事务提交时都要求将redolog刷新到磁盘，那么带来的IO代价必然影响到引擎执行效率，innodb具备innodb_flush_log_at_trx_commit配置项，来进行控制。其选项值的不同代表着不同的策略：
- 0：表示事务提交不立即向磁盘同步redo log，而是交由后台线程处理。这样的好处时加快处理请求的速度，但是如果服务崩溃，后台线程也没来得及刷新redo log，这时候会丢失事务对页面的处理
1：表示每次事务提交都需要将redo log同步到磁盘，可以保证事务的持久性，这也是
innodb_flush_log_at_trx_commit的默认值2：表示事务提交时，将redo log写到操作系统的缓冲区中，但是并不需要真正持久化到磁盘，这样事务的持久性在操作系统没有崩溃的时候还是可以保证，但是如果操作系统也崩溃那么还是无法保证持久性
六丶redo log用于崩溃恢复
1.确定恢复的起点
如果redo log对应的lsn小于checkpoint的话，意味这部分日志对应的脏页已经刷新到了磁盘中，是不需要进行恢复的。但是大于checkpoint的redo log，也许时需要恢复的，也许不需要，因为刷新脏页到磁盘是异步进行的，可能刷新脏页到磁盘但是没来得及修改checkpoint。这时候需要从对应lsn的值为checkpoint_lsn的redo log开始恢复
redo log日志文件组有checkpoint1和checkpoint2记录checkpoint_lsn的值，我们需要选取最近发生的checkpoint信息，也就是将二者中的checkpoint_no拿出来比较比较，谁大说明谁存储了最近一次checkpoint信息，从而拿到最近发生checkpoint的checkpoint_lsn以及其对应的在redo 日志文件组中偏移量checkpoint_offset
2.确定恢复的终点
写入redo log到redo日志文件中redo log block中时，是顺序写入的，先写满一个block再写下一个block，每一个block的log block header部分有一个log_block_hdr_data_len来记录当前lock block使用了多少字节（从12开始，因为lock block header占用了12字节），随着越来越多的日志写入block最后最大为512字节`,所有如果此值小于512那么说明，当前这个block就是崩溃恢复需要扫描的最后一个block。
在mysql进行崩溃恢复的时候，只需要从checkpoint_lsn在日志文件组中对应的偏移量开始，扫描到第一个log_block_hdr_data_len值不为512的block为止
3.如何进行崩溃恢复
现在确定了需要恢复的redo log，那么如何进行恢复昵，每一个redo log格式如下
3.1化随机io为顺序io
其space id记录了表空间号，page number记录了页号，也许这一堆redo log整体上表空间号，页号是不具备顺序的，如果直接遍历每一个redo log然后对表空间中的页进行恢复，是会带来很多随机io的，所以innodb使用hash表进行优化，将相同表空间号和页号作为key，这样相同表空间和页的日志就会在同一个hash桶中形成链表中，然后遍历每一个hash表的操作，一次性将一个页进行恢复，化随机io为顺序io
3.2跳过不需要刷新页
首先小于最近一次checkpoint_lsn的redo log肯定是不需要进行恢复，但是大于的也不一定需要恢复，因为可能在做崩溃前的checkpoint的时候，后台线程也许将LRU链表和flush链表中的一些脏页刷新到磁盘了，那么恢复的时候这些脏页也不需要进行恢复。那么怎么判断这些不需要恢复的脏页昵？——每一个页面具备file header，其中有一个属性为file_page_lsn的属性，记录了最近一次修改页面时对应的lsn值（即脏页在buffer pool控制块中的newest_modification）如果执行某次checkpoint发现页中的lsn大于最近一次checkpoint的checkpoint_lsn的时候，那么说明此页不需要进行更新。
