详解MySQL 重做日志(redo log)与回滚日志(undo logo)

前言:

前面文章讲述了 MySQL 系统中常见的几种日志,其实还有事务相关日志 redo log 和 undo log 没有介绍。相对于其他几种日志而言, redo log 和 undo log 是更加神秘,难以观测的。本篇文章将主要介绍这两类事务日志的作用及运维方法。

1.重做日志(redo log)

我们都知道,事务的四大特性里面有一个是 持久性 ,具体来说就是只要事务提交成功,那么对数据库做的修改就被永久保存下来了,不可能因为任何原因再回到原来的状态。那么 MySQL 是如何保证一致性的呢?最简单的做法是在每次事务提交的时候,将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题,主要体现在两个方面:

  • 因为 Innodb 是以页为单位进行磁盘交互的,而一个事务很可能只修改一个数据页里面的几个字节,这个时候将完整的数据页刷到磁盘的话,太浪费资源了。
  • 一个事务可能涉及修改多个数据页,并且这些数据页在物理上并不连续,使用随机 IO 写入性能太差。

因此 MySQL 设计了 redo log ,具体来说就是只记录事务对数据页做了哪些修改,这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。

redo log 包括两部分:一个是内存中的日志缓冲(redo log buffer),另一个是磁盘上的日志文件(redo log file)。MySQL 每执行一条 DML 语句,先将记录写入 redo log buffer ,后续某个时间点再一次性将多个操作记录写到 redo log file 。

默认情况下,redo log 在磁盘上由名为 ib_logfile0 和 ib_logfile1 的两个物理文件展示。redo log 相关参数简单介绍如下:

  • innodb_log_files_in_group:redo log 文件的个数,命名方式如:ib_logfile0,iblogfile1... iblogfilen。默认2个,最大100个。
  • innodb_log_file_size:单个 redo log 文件设置大小,默认值为 48M,最大值为512G,注意最大值指的是整个 redo log 系列文件之和,即(innodb_log_files_in_group * innodb_log_file_size )不能大于最大值512G。
  • innodb_log_group_home_dir:指定 redo log 文件组所在的路径,默认./ ,表示在数据库的数据目录下。
  • innodb_log_buffer_size:redo log buffer 大小,默认16M。延迟事务日志写入磁盘,把 redo log 放到该缓冲区,然后根据 innodb_flush_log_at_trx_commit 参数的设置,再把日志从 buffer 中 flush 到磁盘中。
  • innodb_flush_log_at_trx_commit:控制 redo log 刷新到磁盘的策略,默认为1。值为1,每次 commit 都会把 redo log 从 redo log buffer 写入到 system ,并 fsync 刷新到磁盘文件中。值为2,每次事务提交时 MySQL 会把日志从 redo log buffer 写入到 system ,但只写入到 file system buffer,由系统内部来 fsync 到磁盘文件。如果数据库实例 crash ,不会丢失 redo log,但是如果服务器 crash,由于 file system buffer 还来不及 fsync 到磁盘文件,所以会丢失这一部分的数据。值为0,表示事务提交时不进行写入 redo log 操作,这个操作仅在 master thread 中完成,而在 master thread 中每1秒进行一次重做日志的 fsync 操作,因此实例 crash 最多丢失1秒钟内的事务。

更改 redo log 及其 buffer 大小是需要重启数据库实例的,建议初始化时做好评估。可以适当加大 redo log 组数和大小,特别是你的数据库实例更新比较频繁的情况下。但也不推荐 redo log 设置过大。

2.回滚日志(undo log)

undo log 主要用于保证数据的原子性,保存了事务发生之前的数据的一个版本,可以用于回滚。比如一条 INSERT 语句,对应一条 DELETE 的 undo log ,对于每个 UPDATE 语句,对应一条相反的 UPDATE 的 undo log ,这样在发生错误时,就能回滚到事务之前的数据状态。同时,undo log 也是 MVCC (多版本并发控制) 实现的关键。

MySQL 5.7 版本中,undo log 默认存放在共享表空间 ibdata 中。也可以在初始化时通过配置参数改成独立的文件,简单介绍几个 undo log 相关参数:

  • innodb_max_undo_log_size:控制最大 undo tablespace 文件的大小,当启动了innodb_undo_log_truncate 时,undo tablespace 超过 innodb_max_undo_log_size 阀值时才会去尝试truncate。该值默认大小为1G,truncate后的大小默认为10M。
  • innodb_undo_tablespaces:设置 undo 独立表空间个数,范围为0-128,5.7版本默认为0,0表示不开启独立undo表空间。该参数只能在最开始初始化 MySQL 实例的时候指定。
  • innodb_undo_directory:设置 undo 表空间的存放目录,默认数据目录。
  • innodb_undo_log_truncate:设置 undo 表空间是否自动截断回收。该参数生效的前提是,已设置独立表空间且独立表空间个数大于等于2个。

undo log 相关参数一般很少改动。MySQL 8.0 默认启用了独立表空间,可能 undo log 表空间的大小设置更灵活些。

总结:

本篇文章主要介绍了 redo log 及 undo log 的作用和相关参数设置,文章写的比较匆忙,如有错误,可以留言指出。关于这两类日志更深层次的内容,可能笔者功力还不到,未能写到更加透彻。好了,MySQL 相关日志的两篇文章已经写完了,希望各位能学到一点知识。

(0)

相关推荐

  • 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数据库清理binlog日志命令详解

    概述 今天主要分享下mysql数据库应该如何正确的删除binlog日志,这里要注意不要强制使用rm命令进行清除.否则mysq-bin.index错乱,最终导致后期expire-log-days配置项失效. 1.查看binlog日志 mysql> show binary logs; 2.删除某个日志文件之前的所有日志文件 purge binary logs to 'mysql-bin.000035'; 3.清理2019-09-09 13:00:00前binlog日志 PURGE MASTER LO

  • MySQL redo死锁问题排查及解决过程分析

    问题背景 周一上班,首先向同事了解了一下上周的测试情况,被告知在多实例场景下 MySQL Server hang 住,无法测试下去,原生版本不存在这个问题,而新版本上出现了这个问题,不禁心头一颤,心中不禁感到奇怪,还好现场环境还在,为排查问题提供了一个好的环境,随即便投入到紧张的问题排查过程当中.问题实例表现如下: 复制代码 代码如下: 并发量为 384 的时候出现的问题: MySQL 服务器无法执行事务相关的语句,即使简单的 select 语句也无法执行: 所有线程处于等待状态,无法 KILL

  • mysql中general_log日志知识点介绍

    以下操作演示都是基于mysql5.6.36版本: 工作中经常遇到这样的问题:mysql数据访问能量很大,想要从sql方面优化.研发经常会问到能看到哪些SQL执行比较频繁吗?回道:不能哦,只能看到当前正在运行的SQL和慢日志里记录的SQL.因为为了性能考虑,一般general log不会开启.slow log可以定位一些有性能问题的sql,而general log会记录所有的SQL.然而有时候生产上的mysql出现性能问题,短时间开启general log,来获取sql执行的情况,对排查和分析my

  • mysql日志触发器实现代码

    sql语句 DROP TRIGGER IF EXISTS sys_menu_edit; CREATE TRIGGER sys_menu_edit BEFORE UPDATE ON sys_menu FOR EACH ROW BEGIN INSERT INTO `g4m`.`sys_log` ( `table_name`, `val_id`, `data_json` ) VALUES ( 'sys_menu', old.id, CONCAT( "{", CONCAT_WS( ',', C

  • Mysql在线回收undo表空间实战记录

    1 Mysql5.6 1.1 相关参数 MySQL 5.6增加了参数innodb_undo_directory.innodb_undo_logs和innodb_undo_tablespaces这3个参数,可以把undo log从ibdata1移出来单独存放. innodb_undo_directory:指定单独存放undo表空间的目录,默认为.(即datadir),可以设置相对路径或者绝对路径.该参数实例初始化之后虽然不可直接改动,但是可以通过先停库,修改配置文件,然后移动undo表空间文件的方

  • mysql将bin-log日志文件转为sql文件的方法

    查看mysqlbinlog版本 mysqlbinlog -V [--version] 查看binlog日志开启状态 show variables like '%log_bin%'; mysql打开bin-log日志后,mysql数据库的非查询操作会将记录保存到bin-log文件中.一般bin-log日志文件不能打开查看的,需要用到mysql的工具进行.假设/mysql/data/目录中存放着二进制文件mysql-bin.000011.需要将日志文件mysql-bin.000011中关于数据库ti

  • MySQL5.7慢查询日志时间与系统时间差8小时原因详解

    在对慢查询进行查看的时候发现时间不对,正好与系统时间相差8个小时. 1.慢查询显示时间如下 # Time: 2020-01-10T06:42:24.940811Z 2.系统时间 $ date Fri Jan 10 14:42:31 CST 2020 3.查看数据库参数 mysql> show variables like 'log_timestamps'; +----------------+-------+ | Variable_name | Value | +----------------

  • MySQL中常见的几种日志汇总

    前言: 在 MySQL 系统中,有着诸多不同类型的日志.各种日志都有着自己的用途,通过分析日志,我们可以优化数据库性能,排除故障,甚至能够还原数据.这些不同类型的日志有助于我们更清晰的了解数据库,在日常学习及运维过程中也会和这些日志打交道.本节内容将带你了解 MySQL 数据库中几种常用日志的作用及管理方法. 1.错误日志(errorlog) 错误日志记录着 mysqld 启动和停止,以及服务器在运行过程中发生的错误及警告相关信息.当数据库意外宕机或发生其他错误时,我们应该去排查错误日志. lo

  • 详解MySQL 重做日志(redo log)与回滚日志(undo logo)

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

  • MySQL事务日志(redo log和undo log)的详细分析

    目录 前言 1.redo log 1.1 redo log和二进制日志的区别 1.2 redo log的基本概念 1.3 日志块(log block) 1.4 log group和redo log file 1.5 redo log的格式 1.6 日志刷盘的规则 1.7 数据页刷盘的规则及checkpoint 1.8 LSN超详细分析 1.9 innodb的恢复行为 1.10 和redo log有关的几个变量 2.undo log 2.1 基本概念 2.2 undo log的存储方式 2.3 和

  • MySQL中的redo log和undo log日志详解

    MySQL日志系统中最重要的日志为重做日志redo log和归档日志bin log,后者为MySQL Server层的日志,前者为InnoDB存储引擎层的日志. 1 重做日志redo log 1.1 什么是redo log redo log用于保证事务的持久性,即ACID中的D. 持久性:指一个事务一旦被提交,它对数据库中数据的改变就是永久性的,接下来即使数据库发生故障也不应该对其有任何影响. redo log有两种类型,分别为物理重做日志和逻辑重做日志.在InnoDB中redo log大多数情

  • 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重做日志 redo log

    目录 一.redo log概念 二.缓存.磁盘结构 在事务的ACID特性中,原子性(A).一致性(C).持久性(D)由undo log和redo log实现,隔离性(I)由锁+MVCC实现 undo log:事务还没有commit,中途执行异常,可以使用undo log把数据恢复到事务执行前的状态,确保事务的原子性 redo log:事务commit成功,由于更新磁盘数据需要一段时间,此时若发生异常,可以使用redo log重新执行这一事务的SQL,确保事务的持久性(只要事务commit成功,不

  • MySQL回滚日志(undo log)的作用和使用详解

    目录 一.undo log的概念 二.undo log的作用 三.undo log的存储机制 四.undo log的工作原理 五.undo log的相关参数 一.undo log的概念 undo log是mysql中比较重要的事务日志之一,顾名思义,undo log是一种用于撤销回退的日志,在事务没提交之前,MySQL会先记录更新前的数据到 undo log日志文件里面,当事务回滚时或者数据库崩溃时,可以利用 undo log来进行回退. 二.undo log的作用 在MySQL中,undo l

  • 详解 Mysql 事务和Mysql 日志

    事务特性 1.原子性(Atomicity):事务开始后所有操作,要么全部做完,要么全部不做,不可能停滞在中间环节. 2.一致性(Consistency):事务开始前和结束后,数据库的完整性约束没有被破坏 .比如A向B转账,不可能A扣了钱,B却没收到. 3.隔离性(Isolation):同一时间,只允许一个事务请求同一数据,不同的事务之间彼此没有任何干扰.比如A正在从一张银行卡中取钱,在A取钱的过程结束前,B不能向这张卡转账. 4.持久性(Durability):事务完成后,事务对数据库的所有更新

  • 详解mysql慢日志查询

    慢日志查询作用 慢日志查询的主要功能就是,记录sql语句中超过设定的时间阈值的查询语句.例如,一条查询sql语句,我们设置的阈值为1s,当这条查询语句的执行时间超过了1s,则将被写入到慢查询配置的日志中. 慢查询主要是为了我们做sql语句的优化功能. 慢日志查询配置项说明 打开mysql,通过以下命令查看相关配置: mysql> show variables like '%query%'; +------------------------------+---------------------

  • 一文详解MySQL Binlog日志与主从复制

    目录 1. Binlog日志的介绍 2. 主从复制 2.1 主从复制的流程 2.2 GTID 2.3 复制模型 2.4 MGR模式 2.5 并行回放 1. Binlog日志的介绍 Binlog是Binary log的缩写,即二进制日志.Binlog主要有三个作用:持久化时将随机IO转化为顺序IO,主从复制以及数据恢复.本文重点主从复制相关的问题. Binlog日志由一个索引文件与很多日志文件组成,每个日志文件由魔数以及事件组成,每个日志文件都会以一个Rotate类型的事件结束. 对于每个事件,都

  • 详解MySQL中事务的持久性实现原理

    前言 说到数据库事务,大家脑子里一定很容易蹦出一堆事务的相关知识,如事务的ACID特性,隔离级别,解决的问题(脏读,不可重复读,幻读)等等,但是可能很少有人真正的清楚事务的这些特性又是怎么实现的,为什么要有四个隔离级别. 在之前的文章我们已经了解了MySQL中事务的隔离性的实现原理,今天就继续来聊一聊MySQL持久性的实现原理. 当然MySQL博大精深,文章疏漏之处在所难免,欢迎批评指正. 说明 MySQL的事务实现逻辑是位于引擎层的,并且不是所有的引擎都支持事务的,下面的说明都是以InnoDB

随机推荐