认识达内从这里开始

日志系统的应用在许多软件编程开发项目中都是非常常见的一个编程技术，而本文我们就通过案例分析来简单了解一下，redo日志应用方法分享。

redo日志

为了保证事务的持久性，在事务提交动作完成之前，需要把该事务修改所有页面都刷新到磁盘，但是存在以下问题

随机I/O比较慢，一个事务可能修改到多个页面，这些页面在磁盘中可能不相邻，可能需要多次长距离移动磁盘读写磁头。

刷新完整的数据页面较慢，一个事务也可能值修改页面中一个字节，却要同步整个页面到磁盘上。

为了解决上述到问题，InnoDB设计了redo日志，把事务修改的内容采用特定的格式按顺序保存到磁盘上，即使在系统崩溃之后，按照redo日志重新更改数据页进行数据恢复即可。

redo日志格式

type，redo日志类型，通过定义不同类型可以达到节省空间的目的

spaceid，表空间id

pagenumber，页号

data，redo日志具体内容

往表中插入一条记录，可能产生多条redo日志，因为可能产生聚簇索引对应B+树页面的分裂操作，可能需要性申请数据页，金额可能要修改各种段、区的统计信息等，终插入一条记录可能产生多条redo日志，这些日志是不可分割的，在崩溃恢复时，也是将这一组日志作为不可分割的整体来处理，类似的，将一组不可分割的redo日志称为Mini-Transaction，即MTR

redo日志缓冲区

为了避免频繁的磁盘IO，并不是每生成一条redo日志就同步到磁盘上。而是先将redo日志放到缓冲区，在特定时机刷新到磁盘。

redo日志是以MTR为单位写入到redo日志缓冲区的，redo日志缓冲区是有若干个512B大小的block构成的一片连续的内存空间，InnoDB引擎使用lsn(logsequencenumber)来记录系统当前有多少redo日志写入到缓冲区

redo日志文件

InnoDB会将lsn相关信息写入到flush链表中，进而方便判断哪些redo日志文件可以被重复使用，

因为只要脏页被刷新到磁盘，相应的redo日志内容就没有存在的意义了，而且redo日志文件大小也有限。

flush链表的基节点start指针出发，flush链表的脏页时按照一次修改发生的时间倒序排列的，也就是按照oldest_modification代表的lsn值倒叙排列，

当页面被多次更新时，会更新对应页面的newest_modification变量的值。

redo日志文件格式

磁盘上存在多个redo日志文件，会被循环使用，这一组redo日志文件称为redo日志文件组。

和redo日志缓冲区一样，redo日志文件也是由若干个512B构成的block组成

其中，redo日志文件的头2048个字节用于存储一些管理信息，系统会将checkpoint操作得到的checkpoint_lsn赋值到checkpoint1的checkpoint_lsn上。

崩溃恢复会从checkpoint_lsn在日志文件组中对应的偏移量开始。

除了前面阐述的checkpoint，redo日志刷盘时机还包括

奔溃恢复

当遇到异常情况导致服务器挂掉，在重启时可以根据redo日志文件恢复到奔溃前的状态。

InnoDB从redo日志文件组的一个文件的checkpoint信息，然后从checkpoint_lsn在日志文件组中对应的偏移量开始，一直扫描日志文件中的，直到某个block的写入量的值不等于512，根据redo日志格式将修改的内容恢复到奔溃前状态。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。