MySQL的日志 - undo log

微信搜索『coder-home』,或者扫一扫右侧的二维码,关注『程序猿集锦』。
了解更多干货分享,还有各类视频教程。
扫描它,带走我。
MySQL的日志 - undo log_第1张图片

文章目录

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

前言

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

什么是undo log

undo log,就是大家经常所说的回滚日志。

它里面记录的是对数据的回滚操作。当我们对数据库中的数据有变动操作的时候,为了可以回滚到数据被改动之前的版本,就把数据的变动过程的逆向操作给记录在undo log中。我们对数据库的查询查找是不会记录undo log的,只有数据库中的数据有变化的操作才会记录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版本中有一点不一样,接下来分别说明一下。
MySQL的日志 - undo log_第2张图片

和系统表空间存放在一起

在MySQL5.6.3之前的版本中,这个undolog table space是和system tablespace系统表空间存放在一起的,如上图中红色框选的部分,因为系统表空间对应的磁盘上面的数据文件就是ibdata1这个文件,所以在MySQL的相关目录下面,我们看不到任何关于undolog相关的数据文件。

独立的undolog表空间

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)

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_page_size的大小 undolog表空间数据文件收缩后的值
    16KB(默认值) 10MB(undolog表空间数据文件初始大小)
    4KB 7MB
    8KB 8MB
    32KB 20MB
    64KB 40MB

    这里我们要知道innodb中的页大小支持4KB、8KB、16KB(默认值)、32KB、64KB。当innodb_page_size的值不同的时候,在收缩undolog表空间大小的时候,就收缩到上面表中对应的大小,这些大小也就是在初始化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__trunc.log,表示正在回收该日志文件,不能向这个日志文件中写入undo日志。同时如果在回收这个日志文件的时候,数据库异常重启,也可以根据这个标识文件继续进行回收undo表空间的操作。当回收表空间的操作结束后,就删除undo__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)
    

    它定义了undo tablespace的表空间文件中包含的回滚段rollback segments的数目。默认值为128,这也是它的最大值,128个回滚段是innodb所能支持的最大的回滚段的数目。官方文档中建议这个值设置为>=35的值,这里说一下为什么。

    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可以全部给独立的回滚表空间来用。

    每一个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
    

    另外,我们需要注意的是如果参数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#
  • 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

最后

undolog回滚日志就写到这里了,后面会分享MySQL的一般查询日志和错误日志。

微信搜索『coder-home』,或者扫一扫右侧的二维码,关注『程序猿集锦』。
了解更多干货分享,还有各类视频教程。
扫描它,带走我。
MySQL的日志 - undo log_第3张图片

你可能感兴趣的:(MySQL,数据库,mysql,undo,log,回滚日志)