MySQL的日志 - undo log

微信搜索『coder-home』，或者扫一扫右侧的二维码，关注『程序猿集锦』。 了解更多干货分享，还有各类视频教程。 扫描它，带走我。

前言

前面我们介绍了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版本中有一点不一样，接下来分别说明一下。

和系统表空间存放在一起

在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』，或者扫一扫右侧的二维码，关注『程序猿集锦』。 了解更多干货分享，还有各类视频教程。 扫描它，带走我。