前言：
InnoDB采用Write Ahead Log策略来防止宕机数据丢失，即事务提交时，先写重做日志，再修改内存数据页，这样就产生了脏页；
- 服务器内存有限，缓冲池不够用，无法缓存全部数据
- 重做日志无限增大成本要求太高
- 宕机时如果重做全部日志恢复时间过长
当数据库宕机时，只需执行上次刷入点Checkpoint后的日志:
- 缩短数据库恢复时间
- 缓冲池不够用时，将脏页刷新到磁盘
- 重做日志不可用时，刷新脏页
重做日志被设计成可循环使用，日志文件写满，已被刷磁盘不再需要的日志可被覆盖重用；
InnoDB引擎通过LSN(Log Sequence Number日志空间每条日志的结束点，字节偏移量表示)标记版本；每个page有LSN，redo log也有LSN，Checkpoint也有LSN。可以通过命令show engine innodb status来观察
有两种Checkpoin：
1、关闭数据库时Sharp Checkpoint将脏页刷回磁盘
2、运行时使用Fuzzy Checkpoint进行部分脏页的刷新
部分脏页刷新有以下几种：
- Master Thread Checkpoint：异步以每秒或每十秒的速度从缓冲池的脏页列表中刷新一定比例的页回磁盘
- FLUSH_LRU_LIST Checkpoint：要保证LRU列表中有100左右空闲页可使用
- Async/Sync Flush Checkpoint：重做日志文件不可用时，需强制将脏页列表中的一些页刷新回磁盘
- Dirty Page too much Checkpoint：脏页数量太多时，InnoDB引擎会强制进行Checkpoint
Log及Checkpoint简介
事务日志是指Redo log，简称Log,保存在日志文件ib_logfile*里面。
另外一个日志Undo log，存放在共享表空间里面的（ibdata*文件）。
紧密相关，因此将这两部分合在一起分析。
名词解释：LSN，日志序列号，Innodb的日志序列号是一个64位的整型。
Log写入：后加
LSN对应日志文件的偏移量，新的LSN＝旧的LSN + 写入的日志大小。举例如下：
LSN＝1G，日志文件大小总共为600M，本次写入512字节，则实际写入操作为：
1、 求出偏移量：由于LSN数值远大于日志文件大小，因此通过取余方式，得到偏移量为400M；
2、写入日志：找到偏移400M的位置，写入512字节日志内容，下一个事务的LSN就是1000000512；
Checkpoint写入：覆盖
每次取到最老的脏页，确保此脏页对应的LSN之前的LSN都已经写入日志文件，再将此脏页的LSN作为Checkpoint点记录到日志文件；恢复数据文件的时候，Innodb扫描日志文件，当发现LSN小于Checkpoint对应的LSN，就认为恢复已经完成。
每次写Checkpoint都覆盖之前的Checkpoint信息
Flush刷新流程及原理介绍
Innodb的一条事务日志共经历4个阶段：
1） 创建阶段：事务创建一条日志；
2） 日志刷盘：日志写入到磁盘上的日志文件；
3） 数据刷盘：日志对应的脏页数据写入到磁盘上的数据文件；
4） 写CKP：日志被当作Checkpoint写入日志文件；
对应这4个阶段，系统记录了4个日志相关的信息，用于其它各种处理使用：
Log sequence number（LSN1）：当前系统LSN最大值，新的事务日志LSN将在此基础上生成（LSN1+新日志的大小）；
Log flushed up to（LSN2）：当前已经写入日志文件的LSN；
Pages flushed up to（LSN3）：当前最旧的脏页数据对应的LSN，写Checkpoint的时候直接将此LSN写入到日志文件；
Last checkpoint at（LSN4）：当前已经写入Checkpoint的LSN；
递减：LSN1>=LSN2>=LSN3>=LSN4
Async/Sync Flush Checkpoint原理
为了避免宕机时数据丢失，保证数据的ACID属性，Innodb至少要保证数据对应的日志不能丢失。对于不同的情况，Innodb采取不同的对策：
1）宕机导致日志丢失
日志刷盘机制，可以通过innodb_flush_log_at_trx_commit参数进行控制；
2）日志覆盖导致日志丢失
日志文件大小是固定的，写入的时候通过取余来计算偏移量，这样存在两个LSN写入到同一位置的可能，后面写的把前面写得就覆盖了，以“写入机制”章节的样例为例，LSN＝100000000和LSN＝1600000000两个日志的偏移量是相同的了。这种情况下，为了保证数据一致性，必须要求LSN=1000000000对应的脏页数据都已经刷到磁盘中，也就是要求Last checkpoint对应的LSN一定要大于1000000000，否则覆盖后日志也没有了，数据也没有刷盘，一旦宕机，数据就丢失了。
为了解决第二种情况导致数据丢失的问题，Innodb实现了一套日志保护机制：
| 概念 | 计算 | 含义 |
| Ckp age | LSN1- LSN4 | 还没有做Checkpoint的日志范围，若Ckp age超过日志空间，说明被覆盖的日志（LSN1－LSN4－Log cap）对应日志和数据“可能”还没有刷到磁盘上 |
| Buf age | LSN1- LSN3 | 还没有将脏页刷盘的日志的范围，若Buf age超过日志空间，说明被覆盖的日志（LSN1－LSN3－Log cap）对应数据“肯定”还没有刷到磁盘上 |
| Buf async | 日志空间大小 * 7/8 | 强制将Buf age-Buf async的脏页刷盘，此时事务还可以继续执行，所以为async，对事务的执行速度没有直接影响（有间接影响，例如CPU和磁盘更忙了，事务的执行速度可能受到影响） |
| Buf sync | 日志空间大小 * 15/16 | 强制将2*(Buf age-Buf async)的脏页刷盘，此时事务停止执行，所以为sync，由于有大量的脏页刷盘，因此阻塞的时间比Ckp sync要长。 |
| Ckp async | 日志空间大小 * 31/32 | 强制写Checkpoint，此时事务还可以继续执行，所以为async，对事务的执行速度没有影响（间接影响也不大，因为写Checkpoint的操作比较简单） |
| Ckp sync | 日志空间大小 * 64/64 | 强制写Checkpoint，此时事务停止执行，所以为sync，但由于写Checkpoint的操作比较简单，即使阻塞，时间也很短 |
当事务执行速度大于脏页刷盘速度时，Ckp age和Buf age会逐步增长，当达到async点的时候，强制进行脏页刷盘或者写Checkpoint，如果这样做还是赶不上事务执行的速度，则为了避免数据丢失，到达sync点的时候，会阻塞其它所有的事务，专门进行脏页刷盘或者写Checkpoint。
因此从理论上来说,只要事务执行速度大于脏页刷盘速度，最终都会触发日志保护机制，进而将事务阻塞，导致MySQL操作挂起。
由于写Checkpoint本身的操作相比写脏页要简单，耗费时间也要少得多，且Ckp sync点在Buf sync点之后，因此绝大部分的阻塞都是阻塞在了Buf sync点，这也是当事务阻塞的时候，IO很高的原因，因为这个时候在不断的刷脏页数据到磁盘
转自：https://blog.csdn.net/melody_mr/article/details/48930739
小结：
为了防止数据丢失，重做日志，修改内存数据，过程中借助标记