我们所讲到的四大特性ACID中的D,也就是持久性,实际上就是由redo log来保障的,接下来就来了解一下redolog是如何来保证事务的持久性的。
redolog称为重做日志,记录的是事务提交时数据页的物理修改,是用来实现事务的持久性。
该日志文件由两部分组成:重做日志缓冲(redo log buffer)以及重做日志文件(redo log file),前者是在内存中,后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中, 用于在刷新脏页到磁盘,发生错误时, 进行数据恢复使用,从而保证持久性。
如果没有redolog,可能会存在什么问题的? 我们一起来分析一下。
首先客户端在进行事务操作的时候会发起请求去操作我们的MySQL服务器,在MySQL服务器的InnoDB引擎中,分为内存结构和磁盘结构。
我们知道,在InnoDB引擎中的内存结构中,主要的内存区域就是缓冲池,在缓冲池中缓存了很多的数据页。 当我们在一个事务中,执行多个增删改的操作时,InnoDB引擎会先操作缓冲池中的数据,如果缓冲区没有对应的数据,会通过后台线程将磁盘中的数据加载出来,存放在缓冲区中,然后将缓冲池中的数据修改,此时缓冲区中的数据发生了变更,但是磁盘中的数据并没有发生变更,修改后的数据页我们称为脏页。 而脏页则会在一定的时机,通过后台线程刷新到磁盘中,从而保证缓冲区与磁盘的数据一致。 而缓冲区的脏页数据并不是实时刷新的,而是一段时间之后将缓冲区的数据刷新到磁盘中,假如刷新到磁盘的过程出错了,而提示给用户事务提交成功,但是最终在脏页刷新的时候失败了,而数据却没有持久化下来,这就出现问题了,没有保证事务的持久性。
那么,如何解决上述的问题呢? 在InnoDB中提供了一份日志 redo log,接下来我们再来分析一 下,通过redolog如何解决这个问题。
有了redolog之后,当对缓冲区的数据进行增删改之后,会首先将操作的数据页的变化,记录在redo log buffer中。在事务提交时,会将redo log buffer,也就是重做日志缓冲区中的数据刷新到磁盘文件中,持久化的保存在磁盘文件中。 过一段时间之后,如果刷新缓冲区的脏页到磁盘时,发生错误,此时就可以借助于redo log进行数据恢复,因为在redo log中就记录了当次数据的变化,这样就保证了事务的持久性。 而如果脏页成功刷新到磁盘 或 或者涉及到的数据已经落盘,此时redolog就没有作用了,就可以删除了,所以存在的两个redolog文件是循环写的。
那为什么每一次提交事务,要刷新redo log 到磁盘中呢,而不是直接将buffer pool中的脏页刷新到磁盘呢 ?
如果我们每一次在提交的时候,不需要redo log,直接把buffer pool中的数据刷新到磁盘文件中,可以这么去做,但是存在严重的性能问题,因为我们在事务中进行一组操作的时候,通常来说会操作很多条记录,而这些记录都是随机的去操作我们的数据页的,这个时候就会涉及到大量的随机磁盘io,性能是比较低的。
而如果说我们在进行操作的时候,用到了这个redo log,在事务提交时,我不会把脏页直接刷新,我先把redo log文件异步刷新到磁盘中,由于它是log日志文件,日志文件都是追加的,此时它就是顺序磁盘IO,它的性能是要高于随机磁盘IO的。
更官方回答:因为在业务操作中,我们操作数据一般都是随机读写磁盘的,而不是顺序读写磁盘。 而redo log在往磁盘文件中写入数据,由于是日志文件,所以都是顺序写的。顺序写的效率,要远大于随机写。 这种先写日志的方式,称之为 WAL(Write-Ahead Logging)。
写入日志后,我们再将脏页的数据再刷新到磁盘中。如果说脏页的数据我们顺利的刷新到磁盘中了,此时redo log日志里面所记录的数据变更实际上也就不需要了,所以我们每隔一段时间就会去清理redo log日志,所以这两份日志实际上它是循环写的,并不会永久的保留下来。
![image-20240721175203033](https://img-blog.csdnimg.cn/img_convert/63be7650f9349691577dfa3e5e7626ad.png)
简单来说,redo log就是为了保证我们在进行脏页刷新发生错误时进行数据恢复,从而保证事务的持久性。