聊聊REDO LOG
为什么需要redolog？
那redolog主要是为了保证数据的持久化，我们知道innodb存储引擎中数据是以页为单位进行存储，每一个页中有很多行记录 来存储数据，我们的数据最终是要持久化到硬盘中，那如果我们每进行一次数据的更新都进行一次磁盘的IO来更新数据页，那这样频繁的磁盘IO说我们承受不起的，所以我们引入了buffer poll，当我们查询一条记录时会把一整页的数据加载出来放到buffer poll中，后续的查找只需要查找buffer poll中有没有数据，有则更新buffer poll中的数据再进行刷盘操作完成数据持久化，与内存进行IO的效率明显远高于磁盘IO，虽然效率是提高了但我们也发现如果我们的MySQL实例挂了或者宕机，内存中数据丢失，我们更新buffer poll中的数据尚未刷盘到磁盘就会造成数据的丢失。所以们需要redolog日志来保证事务的持久性
redolog是如何保证事务持久性的？
我们先来看一下一个更新操作的流程图
第一步，先将需要更新的记录从磁盘中读入到内存中，修改数据的内存拷贝
第二步，生成一条重做日志记录到redo log buffer中，记录的是数据修改后的值
第三步，事务提交后，通过一定的刷盘时机将redo log buffer中的内容刷新到redo log file中
第四步，将内存中的数据刷新到磁盘
redo log的组成（redo log buffer和redo log file ）
redo log buffer是由一块块redo log block组成，我们将一组组日志记录写入redo log block中，只有redo log block满了才会把redo log block写入到page cache中，再通过调用fsync刷盘到redo log file，我们的redo log写入block是从第一个顺序写入的，一个redo log block写满后再写入写一个，要是redo log buffer中所有的redo log block都满了就会强制把redo log block刷入到磁盘，本质上也就是把512字节的redo log block追加进redo log file中
这里就提到了redo log buffer的刷盘时机
innodb中通过innodb_flush_log_at_trx_commit控制
为0时：延迟写。提交事务时不会将redo log写入os buffer，而是每隔1秒将redo log写入os buffer并调用fsync()刷入磁盘。系统崩溃会丢失一秒钟的数据。
为1时：实时写，实时刷。每次提交事务都将redo log写入os buffer并调用fsync()刷入磁盘。这种方式系统奔溃不会丢失数据，因每次提交事务都写入磁盘，性能比较差
为2时：实时写，延时刷。每次提交事务都将redo log写入os buffer，但并不会马上调用fsync()刷如磁盘，而是间隔1秒调fsync()刷盘。相对于每次提交都写盘和每隔1秒写盘，实时写os buffer延时刷盘是一个数据一致性与性能的之间的这种方案。
redo log file
磁盘上的redo log日志不止一个而是以日志文件组 的形式出现，这些文件以ib_logfile[数字]（数字可以是0、1、2...）的形式进行命名，每个的Redo日志文件大小都是一样的。
我们可以想到写入redo log写入日志文件组的时候从ib_logfile0开始写，写满后写ib_logfile1...如果写到最后一个还写满了怎么办呢？我们接着ib_logfile0写，这些ib_logfile以环形数组形式构成，从头开始写，写到末尾回到头循环写，如下图所示：
可以看到其中有两个重要的属性：
write pos：记录当前位置，一边写一边后移
checkpoint：记录当前要擦除的位置也往后移
流程：每次redo log刷盘到日志文件组时write pos后移，每次MySQL加载日志文件组恢复数据时，清空恢复的redo log并把checkpoint后移，write pos和checkpoint之间空着的部分用来记录新的redo kig，如果write pos追上了checkpoint表示日志文件组 满了，这时候不能再写入新的redo log记录，MySQL得停下来，清空一些记录，把checkpoint推荐一下。
至此我们就清楚了重做日志的执行流程