数据库日志redo和undo

Posted bobo137950263

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数据库日志redo和undo相关的知识,希望对你有一定的参考价值。

数据库的ACID属性

Atomicity:原子性,以事物transact为最小单位,事物中的所有操作,要么都执行完,要么都不执行,不存在一部分操作执行,另一部分操作不执行的情况。

Consistency:一致性,在事物开始和事物完成后,数据库的完整性限制不会改变。

Isolation:隔离性,同一个数据库中同时并发执行多个事务,事物之间的操作不会相互影响。

Durability:持久性,事物完成之后,事物所作的操作会持久存在于数据库中。

 

Redo log 和undo log

Redo log:由DML(insert delete update)操作,引起的页面变化,都需要记录到redo log中,大部分为物理日志

在页面修改完成之后,在脏数据由cache写入到磁盘之前,会写入redo日志中。

日志先行,日志会先写入到磁盘中,数据后写入

聚簇索引/二级索引/undo页面的修改,均需要记录在redo日志中

 

Redo log是啥?官方文档解释如下:

Redo log是一个基于磁盘的数据格式,在数据库灾难恢复过程中,用于恢复未完成的事物,修复数据的。在正常的操作过程中,redo log将来自于SQL 语句或者其他API调用的请求,转化为数据表中的变化,当对数据的改变操作还未完成之前,遭遇了意外的停机,那这些变化会在数据库启动初始化的过程中进行replay重演,这个重演的过程,是在接受client请求之前,就会完成。

默认情况下,redo log在磁盘上的体现,一般是ib_logfile0和ib_logfile1两个文件,mysql以循环的方式,写这两个文件,在redo log中的数据,是以记录变化为编码,这些日志数据,也就体现了数据的变化,在log中的一段内容,就体现了一个已经增加的LSN增量。

在mysql的配置文件中,innodb_log_file_size设置了redo log文件的大小,innodb_log_file_in_group设置了日志文件的个数,这些设置必须重启才能生效,当innodb检测到设置的大小和当前的文件大小不一致时,会设置一个检查点,然后关闭该日志文件,删除旧文件,创建一个设置大小的日志文件,开始写入日志。

Redo log刷盘的组提交

和其他所有兼容ACID模型的数据库引擎一样,innodb数据引擎也是会在事物提交之前,先将redo log文件刷盘,而且innodb还使用了一种组提交机制,同时将多个事务的redo log刷到磁盘中,避免一个事物一个提交,通过该组提交机制,一次日志刷盘操作,会将同时进行的多个事务的redo log提交,提高了中断效率。

 

 

Undo log:由DML    操作导致的数据记录变化,均需要将变化前的镜像,写入到undo log中,是一种逻辑日志。

undo log是啥?官方文档解释如下:

undo log是一组undo log记录的集合,这些undo log记录是关于某个事物的,一个undo log记录中包含了描述如何将最后的更新回退到集群索引记录的信息,如果有某一个事物需要去使用原始数据(比如在一个一致性的读事物中),这些原始没有被修改的数据,就会通过undo log记录进行恢复。Undo log存在于undo log段中,undo log段中包含了回滚段,而回滚段存在于系统表空间、临时表空间和回滚表空间中。

Innodb支持128个回滚段,其中有32个是为临时表的事物操作预留的,每一个更新临时表的事物(不包含只读事物)会被分配2个回滚段,一个是启用了redo的回滚段,另一个是没有启用redo的回滚段。只读事物只会分配一个没有启用redo的回滚段,因为只读事物是只允许修改临时表的。

剩下的96个回滚段,每一个都支持1023个一致性数据修改事物,所以能够支持近似于96K的一致性数据修改事物,96K的限制是假设事物不会去修改临时表,如果所有的数据修改事物都修改了临时表,这个大小大约是32K。

 

既然DML操作,会引起redo log和undo log的变化,具体进行分析一下。

Insert 插入操作:

Insert插入操作,不会对原有数据产生影响,只是新产生一条记录和对应的索引,以前的记录和索引不会被修改,所以对undo log的要求不高,但是对redo log的要求就比较高了,用于replay,就需要整条插入的所有信息。

Undo log:记录insert插入记录的主键值

Redo log:记录日志操作页面(space_id,page_no)、完整的插入记录、系统列等

 

Delete删除操作

Delete删除操作是要从当前的库或者表中删除一部分已经存在的记录,如果在删除过程中出现了数据库的crash,在recovery过程中需要再次进行删除操作,而recovery中的replay利用的就是redo log,所以redo log中需要记录删除的具体信息,比如主键等关键信息;而在undo log中需要记录的信息就会更多了,因为有可能在执行删除事物之前,存在一个一致性的读事物,需要读取当前被删除的这些记录,所以这些删除的记录的原始数据,是要存放在undo log中的;另外,由于读查询是会使用到索引等信息,所以这些索引信息,也是要存放在undo log中的。所以综上:

Redo log:记录日志操作页面、删除记录的系统列,记录在页面中的位置,同时记录undo page的修改

Undo log:

  1. Delete操作在innodb中为delete mark操作,并不是真的删除数据,只是将记录标记为delete
  2. 记录当前删除记录的系统列
  3. 记录当前删除记录的主键
  4. 记录当前删除记录的所有索引

 

Update操作

Update的操作分为三种情况,对于不同的操作情况,redo log和undo log中记录的信息也是不一样的。

Section 1:未修改索引,修改的属性列长度不变

在这种update场景中,只是对非索引列的值进行了修改,并未修改该列的长度,所以在redo log中,会进行定点的update,会记录的是update log;而在undo log中,需要记录的是update操作的系统列、操作记录的主键、操作记录该列的原值,如果该update列中包含二级索引,二级索引的原值,也需要记录到undo log中。综上:

Redo log:记录update redo log,如果更新列中包含二级索引,则需要对二级索引进行delete mark操作,然后重新insert一条新的二级索引;同时对undo 页面的修改,同步也要写入到redo log中。

Undo log:记录update的系统列、操作记录的主键、操作记录该列的原值。如果该update列中包含二级索引,二级索引的原值,也需要记录到undo log中

Section 2:未修改索引,修改了属性列长度

这种update场景和section 1中的场景类似,唯一的区别是属性列长度发生了变化,这中变化,在undo log中记录的信息,和section 1中的信息形同,而redo log中记录的信息会发生变化,这个时候记录的不再是定点的update,应该是先delete原始的信息,然后insert一条信息。

undo log:记录信息和section 1中的undo log信息相同

redo log:不能定点的update了,会记录delete+insert redo log

section 3:修改索引列值

在数据库中,修改某条记录的索引列值,实际上的操作是将该记录delete,然后重新插入一条新的记录,然后生成索引,更新索引表。在这一连串的操作过程中,redo log实际上是要记录一个delete和一个insert的redo log,而undo log上是要记录原始的记录(delete操作)和insert的操作记录。

 

 

LSN:log sequence number

日志序列号,递增产生,一个LSN可以唯一标识一个redo log,其中有一个叫checkpoint LSN,用来标识数据库crash的redo 起始点,LSN和日志文件位置意义对应。

以上是关于数据库日志redo和undo的主要内容,如果未能解决你的问题,请参考以下文章

Oracle——redo+undo总结

ORACLE中,数据库的redo与undo分别是啥呀,两者是啥关系呢?

分布式事务和mysql中undo和redo日志

理解数据库中的undo日志redo日志检查点

(26)redo和undo区别

redo和undo的区别是啥