MySQL是怎么保证持久性的(redo log日志相关)

Mysql中 事务的很多实现,都是因为有日志的支撑,比如binlog、undo log、redo log等 

MySQL是怎么保证持久性的

持久性是指,事务一旦提交,它对数据库的改变就应该是永久性的,接下来的其他操作或故障不能对其有影响。InnoDB 中主要是通过 redo log 来保证事务的持久性。

redo log(重做日志),记录的是事务提交时数据页的物理修改,作用是为了保障在进行脏页刷新时而出现错误所造成的持久性的问题!

redo log 是 InnoDB 独有的,记录的是某个数据页做了什么修改,每执行一个事务就会产生相应的 redo log。当事务提交时,只需将 redo log 持久化到磁盘即可,可以暂时不考虑将 Buffer Pool 里的脏页写回,而是在合适的时机交给后台线程去做。系统故障崩溃时,MySQL 也可以在重启之后利用 redo log 里的内容恢复数据。

其中还用到了 WAL 技术。

WAL(Write Ahead Logging-先写日志) 的关键点在于 MySQL 的写操作并不是立刻写到磁盘上,而是先写日志,然后在合适的时间再写到磁盘上。具体来说,当有一条记录需要更新时,InnoDB 引擎会先把物理修改记录写到redo log里【即在commit后会立即将redolog Buffer中redo log的日志信息刷新到磁盘中的redo log file(重做日志文件)中】,这个时候整个记录的更新就算完成了。后续,InnoDB 引擎会在适当的时候,由后台线程将缓存在 Buffer Pool 里的脏页刷新到磁盘里,这个时候往往也是系统空闲的时候,以减少对用户线程的影响。

有了 redo log,当系统崩溃时,即使脏页的数据还没来得及持久化,但 redo log 已经持久化了,MySQL 就可以根据 redo log 里记录的内容,将所有的数据恢复到最新状态,整个过程也就是常说的 crash-safe 能力。

redo log日志文件由两部分构成:

- 重做日志缓冲(redo log buffer)   ---存在内存中

- 重做日志文件(redo log file)     ---存在磁盘中

下面详细阐述一下该过程:

首先用户开启事务,进行一系列的DML(增、删、改)的操作。会先去看内存结构中的缓冲池(Buffer Pool)中是否有要操作的数据,如果有直接操作。

如果没有要先用后台线程将数据从磁盘中读取出来缓存到缓冲池(Buffer Pool)中,然后DML(更新或删除)操作的就是缓冲池中的数据。

操作完缓冲池中的数据后,会立即记录当前事务中的物理修改信息(数据页物理变化)到内存结构中的重做日志缓冲区Redolog Buffer中,

相关说明 :

  • MySQL的Buffer Pool是一个内存区域,用于缓存数据页,从而提高查询性能。读写过程涉及到数据的从磁盘到内存的读取,以及在内存中的修改和写回磁盘。
  • 操作完缓存池中的数据后,数据发生变更,但磁盘中的数据未变,这种数据叫做"脏页",后续需要后台线程找个时机刷新到磁盘中,完成数据的持久化

但是需要注意的是,脏页写回磁盘是由一个后台线程进行的,在MySQL服务器空闲或负载较低时,InnoDB会进行脏页刷盘,以减少对用户线程的影响,降低对性能的影响。

当事务commit提交后,不会立即将该操作后的"脏页"直接刷新到磁盘中,而是等待一定的频率统一将脏页刷新到磁盘中去,保证缓冲池中的数据和磁盘中数据的一致性。

有了redo log后,commit后虽然不会直接刷新到磁盘中,但是在内存结构中的Redolog Buffer会记录事务中的物理修改信息(即数据页变化),在commit后会立即将redolog Buffer中redo log的日志信息刷新到磁盘中的redo log file(重做日志文件)中,持久化的保存在磁盘文件中。

              

这样的话,在一段时间后,Buffer Pool里的脏页刷新到 磁盘的过程中,即使出错了,那么也可以通过磁盘中的redo log file日志文件来进行数据恢复,保证 数据的持久化!

  • 后来脏页中的数据页顺利刷新到磁盘当中后,那么磁盘中的redo log的一些记录信息就没用了。所以每隔一段时间,就会去清理redo log日志!
  • redo log日志文件中有两个文件,这两个文件是循环写的!循环写 就是日志的空间大小是固定的,写满 就需要先刷新脏页,然后继续从头写。

总结:redo log是为了保障在进行脏页刷新时而出现错误所造成的持久性的问题!

思考:

为什么用户commit后,不直接将缓冲池中修改的数据页(脏页)直接刷新回磁盘?

答: 直接将脏页刷新回磁盘,存在严重的性能问题。因为很多DML语句操作数据页的时候,都是随机的。直接操作磁盘,这属于大量的随机磁盘IO。

而commit的时候都是先将redo log日志文件刷新到磁盘中,是因为它是日志文件,日志文件都是追加的形式。这是一种顺序的磁盘IO。效率更高!这种机制叫做 WAL(writting - ahead - logging)

  • 26
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: MySQL中的undologredolog是两种不同的日志文件。 undolog是用于事务回滚的日志文件,它记录了事务执行前的数据状态,当事务回滚时,可以根据这些记录将数据恢复到事务执行前的状态。 redolog是用于崩溃恢复和数据恢复的日志文件,它记录了MySQL数据库中所有的修改操作,当MySQL崩溃或者出现其他异常情况时,可以根据redolog中的记录将数据恢复到最近一次提交的状态。 ### 回答2: MySQL中的undologredolog是两个重要的日志文件,用于维护数据的一致性和恢复。 undolog(回滚日志)是用于回滚操作的日志,它记录了事务对数据库的修改操作,在回滚时可以利用undolog将数据恢复到事务开始前的状态。undolog文件是在InnoDB存储引擎中使用的,它采用了"write ahead logging"(先写日志,再写磁盘)的机制,保证事务的原子性和一致性。 redolog(重做日志)是用于恢复操作的日志,它记录了事务对数据库的修改操作,在数据库崩溃或意外断电等情况下,通过读取redolog可以将数据库恢复到最后一次提交事务的状态。redolog文件是在InnoDB存储引擎中使用的,默认情况下是循环写入,即满了后会从头开始覆盖,以保证磁盘空间的有效利用。 undologredolog的作用不同,undolog主要用于事务回滚,redolog用于恢复数据库。在事务进行过程中,先将数据的修改操作写入undolog,然后再写入redolog,只有当redolog写入成功后,事务才会提交完成。这样可以保证数据库崩溃后,借助redolog进行恢复操作,将未写入磁盘的undolog日志进行恢复。 总结来说,undolog是用于回滚操作,保证了事务的原子性和一致性;redolog是用于恢复操作,保证数据库持久性。两者共同作用,保证MySQL数据库的安全可靠性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值