InnoDB双写机制-redo log执行过程详解，以及宕机处理

目录

一、服务层处理 -- 生成执行计划

二、引擎层的执行过程

1.加载数据页

2.解决数据页损坏问题：数据库双写机制 

3.写入redo log

redo log写入机制

4.checkpoint刷盘机制

刷盘时宕机

---

一、服务层处理 -- 生成执行计划

        服务器接受到请求后，先经过SQL接口，在经过解析器，在经过词法分析和语法分析后生成语法树，进入优化器，优化后得到执行方案，进入执行器，执行器调引擎层处理请求，以上过程比较简单请自行查阅其他资料。

二、引擎层的执行过程

1.加载数据页

        进入引擎层后，若缓冲池（buffer pool）中没有加载该条记录的应在的页，则先对数据页进行加载，在这个过程中，由于mysql的预载机制，通常也会将所在页的前后相邻的页也加载到数据库中。

2.解决数据页损坏问题：数据库双写机制 

        为解决在写入数据页过程中，数据库宕机导致数据页不完整的问题，数据库采用double write双写机制，即数据库在执行更新操作前，先写入double write buffer，再写入redo log buffer，如果这两个操作都执行成功，才会将数据页写入磁盘。

        当我们写入一个page时，先将page写到double write buffer中。在这个过程中如果宕机，此时在数据文件中真实的page不受影响，则可以通过之前的redo log file，恢复到执行语句前的状态。

3.写入redo log

        redo log是物理逻辑日志，它记录了每个页上的修改。redo log 的存在，首先是为了减少数据页从缓冲池刷盘至ibd文件的次数，以及解决刷盘前过程中的脏页问题（未进行刷盘的页，与真实数据不一致）的问题。另一个重要的作用则是保证事务的原子性。redo log分为两个部分，一个是 redo log buffer，即直接读写的缓存，一个是redo log buffer，即其持久化文件。

此时，我们的数据页在我们的缓冲池中，我们添加一条记录，则先在数据页中对其进行修改，所有修改的记录会生成一个redo log，进入到我们的redo log buffer中。

        首先说明由于redo log是物理日志，而且在修改/添加一条记录中，我们很可能修改B+树的多个节点，而且如果记录数目溢出，会触发页分裂，同时可能引起记录的移动，这些都可能导致我们会产生一组（多个）redo。

        

redo log写入机制

        mysql在将数据写入数据页之后，直接将这些redo写入我们的redo log buffer中。之后在默认情况下，innodb不会立即触发将redo写入redo log file中，而是每秒触发一次缓存日志回写磁盘操作，并调用操作系统fsync刷新I/O缓存；如果我们的多个SQL是一个事务，那么在innodb_flush_log_at_trx_commit=1的情况下，我们每次事务提交都会将redo从redo log buffer写入到redo log file中。

这里注意：如果在redo log buffer未写入至redo log file时发生宕机，数据会直接丢失，所以一般情况下，我们要保证数据库参数nnodb_flush_log_at_trx_commit=1

4.checkpoint刷盘机制

        当我们的一个redo log file写满后，innodb会切换到另一个redo log file，切换的过程中，会触发数据库的checkpoint检查点，此时innodb会将double write buffer中的脏页刷新回磁盘，当服务器重启的时候只需要恢复checkpoint之后的数据即可。

        刷盘的过程：先将double write buffer中的数据写入到位于共享表空间的新的数据页中，这个过程是一个异步操作，它会在后台线程中进行。写入完成后，再将新的数据页覆盖掉buffer pool中的数据页

        最后，InnoDB将数据页的信息更新到磁盘上的数据字典中，并且标记数据页为已提交状态。

刷盘时宕机

        若在刷盘过程中宕机，可分为两个阶段：

        1.double write buffer写入共享表空间时宕机：此时ibd中的数据不受影响，可以通过redo log进行恢复

        2.已经写入共享表空间完成，覆盖ibd的过程中宕机：此时ibd中的数据页是缺损的，数据库重启，则innodb首先会查看数据页中LSN的数值，若数据页中的LSN大于redo log，则数据页领先于redo log file刷新回磁盘，不需要进行恢复；反之，数据页中的LSN小于redo log，说明真实数据并没有刷入ibd文件中，则需要从redo log file中，对checkpoint之后的部分数据进行恢复。，将共享表空间的完整的数据页覆盖到ibd文件中

LSN:Log Sequency Numer 日志序列位置，在数据页的File Header 和File Trailer中，占8个字节，前四个字节记录数据页检验和（FIL_PAGE_CHECK_OR_SUM，判断页的完整性），后四个位置记录其在日志序列中的位置

 ·