当前位置:   article > 正文

MySQL的日志 - undo log_undo log存储位置

undo log存储位置
  • 前言
  • 什么是undo log
  • undo log的作用
  • undo log的存储空间
    • 和系统表空间存放在一起
    • 独立的undolog表空间
  • undo log的相关参数
  • 独立undolog表空间的意义

前言
前面我们介绍了MySQL中的慢查询slow query log,二进制日志binlog,中继日志relay log,重做日志redolog,今天我们来看一下另外一个重要的日志:undo log。

什么是undo log
我们执行一个insert语句,在undo log中就记录一个delete语句,用于删除掉刚插入的数据,以此来达到回滚到插入之前的状态;

我们执行了一个update语句,在undo log中也记录一个upate语句,只不过这个update语句的内容是把我们刚才执行update操作的数据内容给修改回去,以此达到回滚到数据修改之前的状态;

我们执行一个delete语句,在undo log中就记录一个insert语句,用于把刚才删除的数据再插入到数据库中,以此来达到回滚到删除之前的状态。

简而言之:undo log中记录的内容是如何把数据还原到变动之前的状态,根据这个日志中的记录,就可以把数据还原到上一个事务提交后的状态。

还用Undo Log来实现多版本并发控制(简称:MVCC)。Undo Log是为了实现事务的原子性。什么是事务的原子性,这里简单提一句:一个事务的所有操作要么全部成功,要么全部失败,不能只提交部分操作。在失败的时候回,需要回滚之前的部分操作,而这个回滚操作就是依赖于我们今天提到的undo log。从undo log里面去回滚数据到事务开启之前的状态。

事务中的所有操作,要么全部完成,要么不做任何操作,不能只做部分操作。如果在执行的过程中发生了错误,要回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过。

而redolog是为了实现事务的持久性,要把所有对数据的修改,持久化到磁盘,只要事务提交成功了,不能因为重启、宕机等原因导致提交的数据丢失了,不见了。这里,把redo和undo两种log对记一下。

事务一旦完成,该事务对数据库所做的所有修改都会持久的保存到数据库中。为了保证持久性,数据库系统会将修改后的数据完全的记录到持久的存储上。

undo log的存储空间

MySQL中的数据存放有对应的表空间,日志的存放也有对应的表空间,一个个表空间对应到磁盘上就是一个个数据文件。undolog也有undolog tablespace的概念,但是undolog的表空间在不同的MySQL版本中有一点不一样,接下来分别说明一下。.

在这里插入图片描述
和系统表空间存放在一起
在5.6.3之后的版本中,MySQL支持将undolog tablespace单独剥离出来,不在和系统表空间放在一起,如上图中绿色框选的部分。而控制undolog单独配置表空间的相关参数如下:

mysql> show variables like '%undo%'; +--------------------------+-----------+ | Variable_name            | Value     | +--------------------------+-----------+ | innodb_max_undo_log_size | 104857600 | | innodb_undo_directory    | ./        | | innodb_undo_log_truncate | ON        | | innodb_undo_logs         | 128       | | innodb_undo_tablespaces  | 4         | +--------------------------+-----------+ 5 rows in set (0.01 sec)  mysql> show variables like 'datadir'; +---------------+-----------------+ | Variable_name | Value           | +---------------+-----------------+ | datadir       | /var/lib/mysql/ | +---------------+-----------------+ 1 row in set (0.02 sec)  mysql> show variables like 'innodb_purge_rseg_truncate_frequency'; +--------------------------------------+-------+ | Variable_name                        | Value | +--------------------------------------+-------+ | innodb_purge_rseg_truncate_frequency | 128   | +--------------------------------------+-------+ 1 row in set (0.02 sec)  mysql> show variables like 'innodb_rollback_segments';/*这个参数是参数innodb_undo_logs的同义词*/ +--------------------------+-------+ | Variable_name            | Value | +--------------------------+-------+ | innodb_rollback_segments | 128   | +--------------------------+-------+ 1 row in set (0.24 sec) 

  • 1
  • 2

undo log的相关参数
使用独立的undolog表空的时候,会使用如下各个参数:

  • innodb_max_undo_log_size:表示每一个undolog对应的日志文件的最大值,默认最大值为1GB大小,默认初始化大小为10MB。日志文件达到该阈值之后,且参数innodb_undo_log_truncate=ON,才会触发truncate回收(收缩)动作,被truncate后的表空间文件大小缩小到undolog表空间数据文件默认的1OMB大小。否则即便是到达最大值之后,也不会自动回收undolog的表空间。这里需要注意一点:在收缩undolog日志文件大小的时候,到底把undolog的表空间文件缩小为多大?这个取决于MySQL中innodb使用的innodb_page_size参数的配置,不同的配置,对应的undolog表空间数据文件的初始大小是不同的,参考下面的表格:
    在这里插入图片描述

  • innodb_undo_directory:表示undolog日志文件的存放目录,值配置的为./,表示日志文件存储在datadir参数所指向的目录下面,从上面可以看出datadir的值为/var/lib/mysql,所以undolog日志文件也会放在这个目录下面。这个参数可以设置相对路径或者绝对路径。参数实例初始化之后虽然不可直接改动,但是可以通过先停库,修改配置文件,然后移动undo表空间文件的方式去修改该参数。在生产环境中,建议给undolog配置单独的磁盘。

  • innodb_undo_log_truncate:表示是否开启自动收缩undolog的表空间的操作。如果配置为ON,并且配置了2个或2个以上的undolog表空间数据文件,当某一个日志文件大小超过设置的最大值之后,就会自动的收缩表空间数据文件。在回收表undolog表空间的时候,会判断这个已经超过设置的单个文件最大值innodb_max_undo_log_size的文件中,是否有还在活跃的事务,如果没有则可以回收该表空间,否则不能回收。对于可以回收的表空间,创建一个表示文件undo_<space_id>trunc.log,表示正在回收该日志文件,不能向这个日志文件中写入undo日志。同时如果在回收这个日志文件的时候,数据库异常重启,也可以根据这个标识文件继续进行回收undo表空间的操作。当回收表空间的操作结束后,就删除undo<space_id>_trunc.log标识文件,此时这个被回收的日志文件可以再次被写入undolog。

    • 注意:在参数innodb_undo_log_truncate配置为ON的时候,则参数innodb_undo_tablespaces的值必须>=2才可以把参数innodb_undo_log_truncate设置为ON。因为在回收表空间数据文件的时候,被回收的表空间数据文件会临时下线,为了保证undolog一直有地方可以写,此时要保证至少还有1个undolog日志文件是在线的。这就是要求innodb_undo_tablespaces>=2的根本原因。
  • innodb_undo_logs(innodb_rollback_segments):这个参数和innodb_rollback_segments是同义词,两者的含义一样。但是innodb_undo_logs在以后的MySQL中会被删除,所以建议使用innodb_rollback_segments这个参数。他们的配置是相同的,只是参数名称不一样而已。

mysql> show variables like 'innodb_rollback_segments'; +--------------------------+-------+ | Variable_name            | Value | +--------------------------+-------+ | innodb_rollback_segments | 128   | +--------------------------+-------+ 1 row in set (0.24 sec)  mysql> show variables like 'innodb_undo_logs'; +------------------+-------+ | Variable_name    | Value | +------------------+-------+ | innodb_undo_logs | 128   | +------------------+-------+ 1 row in set (0.01 sec)

  • 1
  • 2
  1. 它定义了undo tablespace的表空间文件中包含的回滚段rollback
    segments的数目。默认值为128,这也是它的最大值,128个回滚段是innodb所能支持的最大的回滚段的数目。官方文档中建议这个值设置为>=35的值,这里说一下为什么。
  2. 128个回滚段中,需要32个给临时表空间使用,1个给系统表空间使用,此时为32+1=33个,开启独立表空间之后,我们通常还会开启自动回收回滚表空间的操作,所以至少需要2个独立的表空间文件,此时就是33+2=35。这里就是为什么要设置innodb_undo_logs>=35的原因。建议保持默认的128,如果为128,此时innodb_undo_tablespaces的值就可以设置为最大的值95,其中32个分配给了临时表空间。1个给系统表空间。还剩余128-32-1=95个,这95可以全部给独立的回滚表空间来用。
  3. 每一个rollback segments,内部有1024个undo segment 组成。所以,可执行 95*1024个并发事务操作,每个事务占用一个 undo segment slot,注意,如果事务中有临时表事务,还会在临时表空间中的 undo segment slot 再占用一个 undo segment slot,即占用2个undo segment slot。如果错误日志中有:Cannot find a free slot for an undo log。则说明并发的事务太多了,需要考虑下是否要分流业务。

innodb_undo_tablespaces:表示undolog对应的tablespace表空间文件的个数,这里配置的是4,表示在物理磁盘上会有4个undolog表空间文件,可以配置多个undolog表空间文件,文件名称从undo001开始,一直到undo095结束,也就是说最多有95个undolog表空间数据文件。但是这个参数是在MySQL实例化的时候配置好的,配置好之后,不可以再次修改。除非重新实例化MySQL数据库实例。如果强行修改innodb_undo_tablespaces=95,在重启MySQL示例的时候,则会有如下的错误:

2021-01-10T20:01:47.079434+08:00 0 [ERROR] InnoDB: Expected to open 95 undo tablespaces but was able to find only 4 undo tablespaces. Set the innodb_undo_tablespaces parameter to the correct value and retry. Suggested value is 4 2021-01-10T20:01:47.079669+08:00 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error 2021-01-10T20:01:47.695873+08:00 0 [ERROR] Plugin 'InnoDB' init function returned error. 2021-01-10T20:01:47.696568+08:00 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2021-01-10T20:01:47.696825+08:00 0 [ERROR] Failed to initialize builtin plugins. 2021-01-10T20:01:47.697028+08:00 0 [ERROR] Aborting
  • 1
  • 另外,我们需要注意的是如果参数innodb_undo_log_truncate=ON,则参数innodb_undo_tablespaces的值必须满足>=2才可以。
  • Innodb最大支持128个rollback segments回滚段,这128个回滚段分布在system
    tablesapce系统表空间、undo tablespaces回滚表空间和temporary
    tablespace临时表空间中,用于存放回滚数据。
  • 其中32个rollback segments回滚段给temporay
    tablespace临时表空间来使用,因为是临时表,里面的数据随时可能会清除,所以临时表的表空间使用的是rollback
    segments回滚段而不是普通数据段。
  • 剩余的128-32=96个rollback segments回滚段,再拿出1个给system tablespace系统表空间来使用,这里之所以要留1个是系统表空来使用,是因为在MySQL5.6.3之前的版本中,是没有独立的回滚表空间的,在后续的版本中,即便是支持了独立的回滚表空间,这个和系统表空间共享存储的功能也还是支持的,所以这里仍然会给系统表空间中,留下了一个rollback segment。
  • 此时还剩余128-32-1=95个rollback segments回滚段。在回滚表空间中,每一个回滚表空间对应一个回滚段,这就是innodb_undo_tablespaces参数,最多可以配置为95个的原因。
  • innodb_undo_tablespaces参数的值,在MySQL的数据目录下面的效果,如下所示,在/var/lib/mysql目录下面有4个undolog tablespace数据文件。
root@test:/var/lib/mysql# pwd /var/lib/mysql root@test:/var/lib/mysql# du -sh undo* 10M	undo001 10M	undo002 10M	undo003 10M	undo004 root@test:/var/lib/mysql#
  • 1
  • innodb_purge_rseg_truncate_frequency:这个参数表示MySQL后台的purge线程被唤醒多少次之后才触发真正的释放rollback
    segment回滚段的操作,只有当回滚段真正的被释放了,回滚表空间才会被真正的执行truncate收缩操作。从磁盘上看,回滚表空间的数据文件才会变小。该参数越小,undo表空间被尝试truncate的频率越高。默认值为128次。当我们配置了innodb_undo_log_truncate=ON的时候,会结合innodb_purge_rseg_truncate_frequency参数来一起工作,每隔innodb_purge_rseg_truncate_frequency次purge线程被调用,就会触发一次真正的tuncate操作。innodb_undo_log_truncate参数所truncate的回滚段,需要先被innodb_purge_rseg_truncate_frequency参数释放掉才可以被truncate。

独立undolog表空间的意义
我们思考一下:为什么要支持把undolog的tablespace单独剥离出来呢?

这是从性能的角度来考量的。原先的undolog和系统表空间共享一个表空间,这样在记录undolog的时候,和其他的一些使用系统表空间来存储的操作肯定会存在磁盘I/O的竞争。但是如果我们把undolog的表空间单独拉出来,支持让其自定义目录和表空间的数量,这样我们可以把undolog配置单独的磁盘目录,提高undo log日志的读写性能。

从另外一个方面,在5.6.3之前的MySQL版本中,undolog存放在系统表空间中,此时的undo log是无法自动收缩清除,如果有大事务或长事务的存在,就可能导致undulog日志文件越来越大,这就会使磁盘空间使用越来越大,数据库的上线时间越长,这个系统表空间有越来越大,有时候设置导致ibdata1这个文件达到20多个GB,这样导致备份数据库也会越来越长。如果此时我们想回收undulog日志文件的大小,只能把整个库备份后删除重建,然后再把备份的数据导入到新的数据库实例中去。

所以在MySQL的生产环境中,建议配置独立的undolog表空间。一般的配置如下所示:

[mysqld] # undolog回滚表空间的配置 innodb_max_undo_log_size = 1G innodb_undo_directory = /data/mysql/undolog innodb_undo_log_truncate = ON innodb_undo_logs = 128 innodb_undo_tablespaces = 8 innodb_purge_rseg_truncate_frequency = 128
  • 1

END

转载自:http://www.dreamwu.com/post-1901.html

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/凡人多烦事01/article/detail/121910
推荐阅读
相关标签
  

闽ICP备14008679号