1、redo log基本概念

redo log的相关概念这里就不再过多阐述，网上有非常多的好的资料，可以看下缥缈大神的文章：https://www.cnblogs.com/cuisi/p/6525077.html，个人感觉介绍的非常详细。

2、数据更改过程简述

MySQL 在更新数据的时候，都是将数据先从磁盘拉到 buffer pool 中，在buffer pool中修改完成后再写到磁盘中，也就是说MySQL中数据的更改都是要经过buffer pool的。
回到这个更新数据的过程中来看：当数据在buffer pool中更改完成的这一刻，更新后的数据是“最新”的，因为此时磁盘中的数据还是更改前的“旧数据”，而我们都是将磁盘中已经持久化的数据作为“标准数据”，因此此时 buffer pool 中的“最新”数据也常人们被称为“脏数据（dirty data）”。

比如将 update 一百行记录作为一个事务，在这个事务执行过程中会将更新后的数据先写入redo log buffer，redo log buffer 再将数据刷入（请注意刷入这个用语，而非写入，后面会详细介绍）redo log中（这点和 binlog 不同，binlog 是在事务 commit 后一次性写入，而 redo log 在事务执行过程中就会写入）。

3、redo log刷新过程
首先需要明白两个概念：
fsync：传统的unix系统在内核中都设有缓冲区，并且大多数的I/O都会通过缓冲进行。当将数据写入文件时，内核通常先将该数据复制到其中一个缓冲区中，如果该缓冲区尚未写满，则并不将其排入输出队列，而是等待其写满或者当内核需要重用该缓冲区以便存放其他磁盘块数据时，再将该缓冲排入输出队列，然后待其到达队首时，才进行实际的 I/O 操作。这种输出方式被成为延迟写。
unix提供了sync、fsync、fdatasync三个函数，sync只是将所有修改过的块放入写队列，不管它是否写磁盘结束就返回；fsync会等待写磁盘结束才会返回。

O_DIRECT选项：O_DIRECT选项是Linux文件写入中的一个选项，开启了这个选项以后，数据就可以跳过系统层的缓存，直接写入磁盘。

redo log并没有打开O_DIRECT选项，所以redo log buffer只是先刷入redo log file，此时刷入的数据并没有落到磁盘上，而是放在文件系统的缓存中。之后为了确保redo log写入磁盘，就通过fsync操作将数据写入磁盘。（redo log buffer到redo log file只是“刷入”的过程，这个时候并没有写入磁盘，而是写入了OS层的文件系统缓存。）

4、重要参数
innodb_flush_log_at_trx_commit：用来控制redo log刷新到磁盘的策略。

默认值是1，表示每次事务提交的时候都调用fsync来写入到磁盘；
0表示事务在执行过程中，日志一直放在redo log buffer中，但是在事务commit的时候，不写入redo log file，而是通过master线程每秒操作一次，从redo log buffer写入到redo log file中。
2表示事务提交时将redo log buffer刷入redo log file，也即刷入系统文件缓存中，不进行fsync操作，由系统来进行fsync操作。此时如果数据库层宕机，则不会丢失redo log，但是如果服务器宕机，这个时候文件系统中的缓存还没有fsync到磁盘文件中，这个时候就会丢失这一部分数据。