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

目录

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

二、引擎层的执行过程

1.加载数据页

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

3.写入redo log

redo log写入机制

4.checkpoint刷盘机制

刷盘时宕机


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

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

二、引擎层的执行过程

1.加载数据页

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

InnoDB双写机制-redo log执行过程详解,以及宕机处理_第1张图片

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

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

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

InnoDB双写机制-redo log执行过程详解,以及宕机处理_第2张图片

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写入机制

InnoDB双写机制-redo log执行过程详解,以及宕机处理_第3张图片

        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将数据页的信息更新到磁盘上的数据字典中,并且标记数据页为已提交状态。

InnoDB双写机制-redo log执行过程详解,以及宕机处理_第4张图片

刷盘时宕机

InnoDB双写机制-redo log执行过程详解,以及宕机处理_第5张图片

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

        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,判断页的完整性),后四个位置记录其在日志序列中的位置

 ·        

       

你可能感兴趣的:(数据库)