一:为什么需要REDO日志
- 缓冲池可以帮助我们消除CPU和磁盘之间的鸿沟,checkpoint机制可以保证数据的最终落盘,然而由于checkpoint 并不是每次变更的时候就触发 的,而是master线程隔一段时间去处理的。所以最坏的情况就是事务提交后,刚写完缓冲池,数据库宕机了,那么这段数据就是丢失的,无法恢复。
- 事务包含持久性的特性,就是说对于一个已经提交的事务,在事务提交后即使系统发生了溃,这个事务对数据库中所做的更改也不能丢失。
解决思路:先写日志,再写磁盘,只有日志写入成功,才算事务提交成功,这里的日志就是rodo日志
二:什么是REDO日志
Redo Log是MySQL用于实现崩溃恢复和数据持久性的一种机制。在事务进行过程中,MySQL会将事务做了什么改动记录到Redo Log中。当系统崩溃或者发生异常情况时,MySQL会利用Redo Log中的记录信息来进行恢复操作,将事务所做的修改持久化到磁盘中。
三:redo的组成
- 重做日志的缓冲 (redo log buffer) ,保存在内存中,是易失的
- 重做日志文件 (redo log file) ,保存在硬盘中,是持久的
四:redo的整体流程
- 先将原始数据从磁盘中读入内存中来,修改数据的内存拷贝
- 生成一条重做日志并写入redo log buffer,记录的是数据被修改后的值
- 当事务commit时,将redo log buffer中的内容刷新到 redo log file,对 redo log file采用追加
写的方式 - 定期将内存中修改的数据刷新到磁盘中
五:redo log的刷盘策略
redo log的写入并不是直接写入磁盘的,InnoDB引擎会在写redo log的时候先写redo log buffer,之后以一定的频率刷入到真正的redo log file 中。这里的一定频率怎么看待呢?这就是我们要说的刷盘策略。
注意,redo log buffer刷盘到redo log file的过程并不是真正的刷到磁盘中去,只是刷入到 文件系统缓存中去,真正的写入会交给系统自己来决定。那么对于InnoDB来说就存在一个问题,如果交给系统来同步,同样如果系统宕机,那么数据也丢失了。
针对这种情况,InnoDB提供了一个参数,该参数控制 commit提交事务时,如何将 redo log buffer 中的日志刷新到 redo log
- 设置为0 :表示每次事务提交时不进行刷盘操作。(系统默认master thread每隔1s进行一次重做日志的同步)
- 设置为1 :表示每次事务提交时都将进行同步,刷盘操作( 默认值 )
- 设置为2 :表示每次事务提交时都只把 redo log buffer 内容写入 page cache,不进行同步。由os自己决定什么时候同步到磁盘文件。
六:什么是Undo Log日志
Undo Log是事务原子性的保证,在事务中更新数据的前置操作其实是要先写入一个 undo log。如果事务需要回滚,则会从Undo Log中找到相应的记录来撤销事务所做的修改。另外,Undo Log还支持MVCC(多版本并发控制)机制,用于在并发事务执行时提供一定的隔离性。
七:undo log的生命周期
假设有2个数值,分别为A=1和B=2,然后将A修改为3,B修改为4
1. start transaction;
2.记录 A=1 到undo log;
3. update A = 3;
4.记录 A=3 到redo log;
5.记录 B=2 到undo log;
6. update B = 4;
7.记录B = 4 到redo log;
8.将redo log刷新到磁盘
9. commit
在1-8步骤的任意一步系统宕机,事务未提交,该事务就不会对磁盘上的数据做任何影响。
如果在8-9之间宕机,恢复之后可以选择回滚,也可以选择继续完成事务提交,因为此时redo log已经持久化。
若在9之后系统宕机,内存映射中变更的数据还来不及刷回磁盘,那么系统恢复之后,可以根据redo log把数
面试题:
1. redolog和undolog区别?
(1)redo log:记录的是"物理级别"上的页修改操作,比如页号xx、偏移量yyy,写了’zzz’数据
undo log:记录的是逻辑操作,比如对某一行数据进行了INSERT语句操作,那么 undo log就记录一条与之相反的DELETE操作
(2)redo log:目的是为了保证事务的持久性,主要用于崩溃恢复
undo log:目的是为了保证事务的原子性和一致性,主要用于事务回滚