MySQL 撤销日志与重做日志(Undo Log与Redo Log)相关总结

Undo Log

数据库事务开始之前，会将要修改的记录存放到 Undo 日志里，当事务回滚时或者数据库崩溃时，可以利用 Undo 日志，撤销未提交事务对数据库产生的影响。

Undo Log产生和销毁

Undo Log在事务开始前产生；事务在提交时，并不会立刻删除undo log，innodb会将该事务对应的undo log放入到删除列表中，后面会通过后台线程purge thread进行回收处理。
Undo Log属于逻辑日志，记录一个变化过程。例如执行一个delete，undolog会记录一个insert；执行一个update，undolog会记录一个相反的update。

Undo Log存储

Undo log采用段的方式管理和记录。在innodb数据文件中包含一种rollback segment回滚段，内部包含1024个undo log segment。可以通过下面一组参数来控制Undo log存储。

show variables like '%innodb_undo%';

Undo Log作用

实现事务的原子性

Undo Log 是为了实现事务的原子性而出现的产物。事务处理过程中，如果出现了错误或者用户执行了 ROLLBACK 语句，MySQL 可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。

实现多版本并发控制（MVCC）

Undo Log 在 MySQL InnoDB 存储引擎中用来实现多版本并发控制。事务未提交之前，Undo Log保存了未提交之前的版本数据，Undo Log 中的数据可作为数据旧版本快照供其他并发事务进行快照读。

事务A手动开启事务，执行更新操作，首先会把更新命中的数据备份到 Undo Buffer中。
事务B手动开启事务，执行查询操作，会读取 Undo 日志数据返回，进行快照读

Redo Log

指事务中修改的任何数据，将最新的数据备份存储的位置（Redo Log），被称为重做日志。

Redo Log 的生成和释放

随着事务操作的执行，就会生成Redo Log，在事务提交时会将产生Redo Log写入Log Buffer，并不是随着事务的提交就立刻写入磁盘文件。
等事务操作的脏页写入到磁盘之后，Redo Log 的使命也就完成了，Redo Log占用的空间就可以重用（被覆盖写入）。

Redo Log 工作原理

Redo Log 是为了实现事务的持久性而出现的产物。防止在发生故障的时间点，尚有脏页未写入表的 ibd 文件中，在重启 MySQL 服务的时候，根据 Redo Log 进行重做，从而达到事务的未入磁盘数据进行持久化这一特性。

Redo Log 写入机制

Redo Log 文件内容是以顺序循环的方式写入文件，写满时则回溯到第一个文件，进行覆盖写

write pos 是当前记录的位置，一边写一边后移，写到最后一个文件末尾后就回到 0 号文件开头；
checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件；
write pos 和 checkpoint 之间还空着的部分，可以用来记录新的操作。如果 write pos 追上checkpoint，表示写满，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint 推进一下。

Redo Log相关配置参数

每个InnoDB存储引擎至少有1个重做日志文件组（group），每个文件组至少有2个重做日志文件，默认为ib_logfile0和ib_logfile1。可以通过下面一组参数控制Redo Log存储

show variables like '%innodb_log%';

Redo Buffer 持久化到 Redo Log 的策略，可通过 Innodb_flush_log_at_trx_commit 设置

0：每秒提交 Redo buffer ->OS cache -> flush cache to disk，可能丢失一秒内的事务数据。由后台Master线程每隔 1秒执行一次操作。
1（默认值）：每次事务提交执行 Redo Buffer -> OS cache -> flush cache to disk，最安全，性能最差的方式。
2：每次事务提交执行 Redo Buffer -> OS cache，然后由后台Master线程再每隔1秒执行OS cache -> flush cache to disk 的操作。

一般建议选择取值2，因为 MySQL 挂了数据没有损失，整个服务器挂了才会损失1秒的事务提交数据。

以上就是MySQL 撤销日志与重做日志(Undo Log与Redo Log)相关总结的详细内容，更多关于MySQL 撤销日志与重做日志(Undo Log与Redo Log)的资料请关注我们其它相关文章！

赞 (0)

相关推荐

  • MySQL系列之redo log、undo log和binlog详解

    MySQL系列之redo log、undo log和binlog详解

    事务的实现 redo log保证事务的持久性,undo log用来帮助事务回滚及MVCC的功能. InnoDB存储引擎体系结构 redo log Write Ahead Log策略 事务提交时,先写重做日志再修改页:当由于发生宕机而导致数据丢失时,就可以通过重做日志来完成数据的恢复. InnoDB首先将重做日志信息先放到重做日志缓存 按一定频率刷新到重做日志文件 重做日志文件: 在默认情况,InnoDB存储引擎的数据目录下会有两个名为ib_logfile1和ib_logfile2的文件.每个In

  • MySQL Aborted connection告警日志的分析

    前言: 有时候,连接MySQL的会话经常会异常退出,错误日志里会看到"Got an error reading communication packets"类型的告警.本篇文章我们一起来讨论下该错误可能的原因以及如何来规避. 1.状态变量Aborted_clients和Aborted_connects 首先我们来了解下Aborted_clients和Aborted_connects这两个状态变量的含义,当出现会话异常退出时,这两个状态值会有变化.根据官方文档描述,总结如下: 造成Abo

  • mysql中的7种日志小结

    mysql中的7种日志小结

    MySQL中有以下日志文件,分别是: 1:重做日志(redo log) 2:回滚日志(undo log) 3:二进制日志(binlog) 4:错误日志(errorlog) 5:慢查询日志(slow query log) 6:一般查询日志(general log) 7:中继日志(relay log) 其中重做日志和回滚日志与事务操作息息相关,二进制日志也与事务操作有一定的关系,这三种日志,对理解MySQL中的事务操作有着重要的意义. 一.重做日志(redo log) 作用: 确保事务的持久性.re

  • MySQL使用binlog日志做数据恢复的实现

    MySQL使用binlog日志做数据恢复的实现

    MySQL的binlog日志是MySQL日志中非常重要的一种日志,记录了数据库所有的DML操作.通过binlog日志我们可以进行数据库的读写分离.数据增量备份以及服务器宕机时的数据恢复. 定期备份固然可以在服务器发生宕机的时候快速的恢复数据,但传统的全量备份不可能做到实时,所以在发生宕机的时候,也会损伤一部分数据,如果这个时候开启了binlog日志,那么可以通过binlog来对没有做备份的这一阶段损失的数据进行恢复.如果了解Redis的朋友,可能想到了,Redis有两种持久化方式,分别是AOF和

  • 详解监听MySQL的binlog日志工具分析：Canal

    Canal是阿里巴巴旗下的一款开源项目,利用Java开发.主要用途是基于MySQL数据库增量日志解析,提供增量数据订阅和消费,目前主要支持MySQL. GitHub地址:https://github.com/alibaba/canal 在介绍Canal内部原理之前,首先来了解一下MySQL Master/Slave同步原理: MySQL master启动binlog机制,将数据变更写入二进制日志(binary log, 其中记录叫做二进制日志事件binary log events,可以通过sho

  • 详解MySQL 重做日志（redo log）与回滚日志（undo logo）

    前言: 前面文章讲述了 MySQL 系统中常见的几种日志,其实还有事务相关日志 redo log 和 undo log 没有介绍.相对于其他几种日志而言, redo log 和 undo log 是更加神秘,难以观测的.本篇文章将主要介绍这两类事务日志的作用及运维方法. 1.重做日志(redo log) 我们都知道,事务的四大特性里面有一个是 持久性 ,具体来说就是只要事务提交成功,那么对数据库做的修改就被永久保存下来了,不可能因为任何原因再回到原来的状态.那么 MySQL 是如何保证一致性的呢

  • MySQL中的undo日志

    概念介绍: 我们知道,MySQL中的redo日志记录了事务的行为,在服务器宕机的时候,可以通过重做事务来达到恢复数据的目的,然而,有的时候,事务还有回滚的需求,也就是说,我们需要知道某条在变成当前情况之前的样子,这种情况下,undo日志就派上用场了.也就是说,undo日志是为了将数据恢复到修改之前的样子,因此在对数据库进行修改的时候,我们需要知道,这个过程中会产生redo日志和undo日志. 存储位置: 我们还知道,redo日志一般情况下放在redo日志文件中,也就是常说的ib_log中,而un

  • MySQL 慢查询日志的开启与配置

    简介 MySQL 慢查询日志是排查问题 SQL 语句,以及检查当前 MySQL 性能的一个重要功能. 查看是否开启慢查询功能: mysql> show variables like 'slow_query%'; +---------------------+------------------------------------+ | Variable_name | Value | +---------------------+----------------------------------

  • MySQL 一则慢日志监控误报的问题分析与解决

    之前因为各种原因,有些报警没有引起重视,最近放假马上排除了一些潜在的人为原因,发现数据库的慢日志报警有些奇怪,主要表现是慢日志报警不属实,收到报警的即时通信提醒后,隔一会去数据库里面去排查,发现慢日志的性能似乎没有那么差(我设置的一个阈值是60). 排查过几次代码层面的逻辑,没有发现明显的问题,几次下来,问题依旧,这可激发了修正的念头,决定认真看看到底是什么原因. 后端使用的是基于ORM的模式,数据都存储在模型MySQL_slowlog_sql_history对应的表中. 代码层面是类似如下的逻

  • MYSQL SERVER收缩日志文件实现方法

    事务日志记录着在相关数据库上的操作,同时还存储数据库恢复(recovery)的相关信息. 收缩日志的原因有很多种,有些是考虑空间不足,有些则是应用程序限制导致的. 下面介绍的是在简单模式下,进行收缩操作. 一.命令行搞定 USE MASTER GO ALTER DATABASE {DBName} SET RECOVERY SIMPLE WITH NO_WAIT GO ALTER DATABASE {DBName} SET RECOVERY SIMPLE --简单模式 GO USE {DBName

  • MySQL慢查询日志的作用和开启

    前言 MySQL的慢查询日志是MySQL提供的一种日志记录,它用来记录在MySQL中响应时间超过阀值的语句,具体指运行时间超过long_query_time值的SQL,则会被记录到慢查询日志中.long_query_time的默认值为10,意思是运行10S以上的语句.默认情况下,Mysql数据库并不启动慢查询日志,需要我们手动来设置这个参数,当然,如果不是调优需要的话,一般不建议启动该参数,因为开启慢查询日志会或多或少带来一定的性能影响.慢查询日志支持将日志记录写入文件,也支持将日志记录写入数据

随机推荐