Mysql日志之Undo log(回滚日志)

06 Database 评论

1. 什么是Undo log

Undo：意为撤销或取消，以撤销操作为目的，返回某个状态的操作

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

Undo log时事务原子性的保证。在事务更新数据的前置操作其实就是要先写入一个Undo log

2. 如何理解Undo Log

事务需要保证原子性，也就是事务中的操作要么全部完成，要么全部失败。但是有时候事务执行到一半出现一些情况，比如：

  • 情况一：事务执行过程中可能遇到各种错误，比如服务器本身的错误，操作系统错误，甚至时突然断电导致的错误。

  • 情况二：DBA可以在事务执行过程中后动输入ROLLBACK语句结束当前事务的执行。

以上情况出现，我们需要把数据恢复到原来的样子，这个过程称之为回滚。

当我们对数据进行操作时(INSERT、update、delete)都需要把回滚时所需的恭喜记录下来，比如：

  1. 插入记录时，至少需要把这条记录的主键值记录下来，回滚的时候只寻药把这个主键值对应的记录删掉（对于每个INSERT，InnoDB存储引擎都会完成一个DELETE）
  1. 删除记录时，至少需要把删除的内容记录下来，回滚时再把这些内容插入回去(对于每个DELETE，InnoDB存储引擎会执行一个INSERT)
  1. 修改记录时，至少需要把这条记录原来的内容都记录下来，回滚时再把这条记录更新就原来的值(对于每个UPDATE，InnoDB都会执行一个相反的update，将修改前的行放回去)

Mysql 把这些为了回滚而记录的内容称之为撤销日志或者回滚日志(即Undo log)，由于查询操作select并不会修改任何用户记录，所有不需要记录响应的Undo日志。

此外，Undo log也会产生Redo log，也就是Undo log的产生会伴随着Redo log的产生，这是因为Undo log也需要持久性的保护

3. Undo log 的功能

  • 提供数据回滚-原子性

    当事务回滚时或者数据库崩溃时，可以利用undo log来进行数据回滚

  • 多版本并发控制(MVCC)-隔离性

    即在InnoDB存储引擎中MVCC的实现是通过Undo log来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过Undo log读取之前的行版本信息，以此实现非锁定读取。

4. Undo log的存储结构

4.1 回滚段与Undo页

InnoDB对Undo log的管理采用段的方式，也就是回滚段(rollback segment)。每个回滚段记录了1024个Undo log segement，而在每个Undo log segment段中进行Undo页的申请。

在InnoDB1.1版本之前，只有一个rollback segment，因此支持同时在线的事务限制为1024。从1.1版本开始支持最大128个 rollback segment，所以支持同时在线的事务为128 * 1024

1
2
3
4
5
6
mysql> show variables like 'innodb_rollback_segments';  # 1.2版本之前使用：show variables like 'innodb_undo_logs';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_undo_logs | 128   |
+------------------+-------+

虽然InnoDB1.1版本支持128个rollback segment，但是这些rollback segment都存储与共享表空间ibdata中，从InnoDB1.2开始，可以通过参数对rollback segment进行设置：

  • innodb_undo_directory：设置rollback segment文件所在的路径。这意味着rollback segment可以存放在共享表空间以外的位置，即可以设置为独立表空间。该参数的默认值为“./”，表示当前InnoDB存储引擎的目录
  • innodb_undo_logs/innodb_rollback_segments： 设置rollback segment的个数，默认值为128。在InnoDB1.2版本中，该参数用来替换之前版本的参数innodb_rollback_segments

  • innodb_undo_tablespaces：设置构成rollback segment文件的数量，这样rollback segment可以较为平均地分布在多个文件中。设置该参数后，会在路径innodb_undo_directory看到undo为前缀的文件，该文件就代表rollback segment文件

    1
    2
    3
    4
    5
    6
    mysql> show variables like 'innodb_undo_tablespaces';
    +-------------------------+-------+
    | Variable_name           | Value |
    +-------------------------+-------+
    | innodb_undo_tablespaces | 2     |
    +-------------------------+-------+

4.2 回滚段与事务

  1. 每个事务只会使用一个回滚段rollback segment，一个回滚段在同一个时刻可能会服务于多个事务。
  1. 当一个事务开始的时候会指定一个回滚段，在事务进行的过程中，当数据被修改时，原始的数据会被复制到回滚段。
  1. 在回滚段中，事务会不断填充盘区，直到事务结束或所有的空间被用完。如果当前的盘区不够用，事务会在段中请求扩展下一个盘区，如果所有已分配的盘区都被用完了，事务会覆盖最初的盘区或在回滚段允许的情况下扩展新的盘区来使用。
  1. 回滚段存在于Undo 表空间中，在数据库中可以存在多个Undo表空间，但同一时刻只能使用一个Undo表空间

  1. 当事务提交时，InnoDB存储引擎会做一下两件事情：

    • 将Undo log放入列表中，以供之后的purge（清洗、清除）操作
    • 判断Undo log所在的页是否可以重用(低于3/4可以重用)，若可以分配给下个事务使用

4.3 回滚段中的数据分类

  1. 未提交的回滚数据(uncommitted undo information)：该数据所关联的事务并未提交，用于实现读一致性，所以该数据不能被其他的事务的数据覆盖
  1. 已提交但为过期的回滚数据(committed undo information)：该数据关联的事务已经提交，但是仍受到undo retention参数的保持时间的影响。
  1. 事务已经提交并过期的数据(expired undo information)：事务已经提交，而且数据保存时间已经超过undo retention参数指定的时间，属于过期数据，当回滚段满了之后，会优先覆盖事务已提交并过期的数据。

4.4 Undo 页的重用

当我们开启一个事务需要写undo log的时候，先去Undo log segment中去找到一个空闲的位置，当有空位的时候就去申请Undo 页，在这个申请到的Undo页中进行Undo log的写入。默认页的大小为16K。

为每一个事务分配一个页，时非常浪费的(除非事务非常长)，假设应用的TPS时1000，那么1s就需要1000页，大概需要16M的存储，1分钟大概需要1G的存储，如果照这样下去除非Mysql清理的非常快，否则随着时间的推移，磁盘空间会增长的非常快，而且很懂空间都是浪费的。

Undo页就被设计的可以重用了，当事务提交时，并不会立刻删除Undo页，因为重用，所以这个Undo页可能混杂这其他事务的Undo log。 Undo log在commit后，会被放到一个连标中，然后判断Undo页的使用空间是否小于3/4,如果小于3/4的话，则表示当前的Undo页可以被重用，那么它就不会被回收，其他事务的Undo log可以记录在当前Undo页的后面。由于Undo log是离散的，所以清理对应的磁盘空间效率不高。

4.5 Undo log日志的存储机制

如上图，可以看到Undo log日志里面不仅存放着数据更新前的记录，还记录着RowId、事务ID、回滚指针。

其中事务ID每次递增，回滚指针第一次如果是Insert的话，回滚指针为NULL，第二次Update之后的Undo log的回滚指针就指向刚刚那一条Undo log日志，以此类推，就会形成一条Undo log的回滚链，方便找到该条记录的历史版本。

5. Undo log的工作原理

在更新数据之前，Mysql会提前生成Undo log日志，当事务提交的时候，并不会立即删除Undo log，因为后面可能需要进行回滚操作，要执行回滚(rollback)操作是，从缓存中读取数据。Undo log日志的删除是通过后台purge线程回收处理的。

  1. 事务A执行Update操作，此时事务还没有提交，会将数据备份到对应的Undo Buffer，然后由Undo Buffer持久化到磁盘中的Undo Log文件中，此时Undo log保存了未提交之前的操作日志，接着将操作的数据，也就是test表的数据持久保存到InnoDB的数据文件IBD。
  1. 此时事务B进行查询操作，直接从Undo Buffer缓存中进行读取，这是事务A还没有条事务，如果要回滚(rollback)事务，是不读磁盘的，先直接从Undo Buffer缓存读取。

6. Undo Log的类型

在InnoDB的存储引擎中，Undo Log分为：

  • insert undo log：insert undo log是指在insert操作中产生的Undo log，因为insert操作的记录，只对事务本省可见，对其他事务不可见（隔离性），所以该Undo log可以在事务提交后直接删除删除，不需要进行purge操作。
  • update Undo log：update undo log记录的是对delete和update操作产生的Undo log，该Undo log可能需要提供MVCC机制，因此不能在事务提交时就删除，提交时放入到Undo log链表，等待purge线程进行最后的删除。

7. Undo log的生命周期

以下是Undo + Redo事务的简化过程：

假设有2个数值，分别是A =1 和 B=2，然后将A修改为3， B修改为4

1
2
3
4
5
6
7
8
9
start transaction;
记录A=1到Undo Log;
Update A = 3;
记录A=3到Redo Log;
记录B=2到Undo log;
update B = 4;
记录B=4到Redo Log;
将Redo log刷新到磁盘;
commit;
  • 在 1-8步骤的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响

  • 如果在8-9之间宕机

    • Redo log进行恢复
    • Undo log发现有事务没完成进行胡滚

  • 若在9之后宕机，内存映射中变更的数据还没有刷回磁盘，那么系统恢复之后，可以根据Redo log把数据刷回磁盘

流程图：

8. Undo Log的配置参数

  • innodb_max_undo_log_size：Undo 日志文件的最大值，默认1GB，初始化大小10M

  • innodb_undo_log_truncate： 表示是否开启自动收缩Undo log表空间的操作

  • innodb_undo_tablespaces：设置独立表空间的个数，默认为0，表示不开启独立表空间,Undo 日志保存在ibdata1中

  • innodb_undo_directory： Undo日志iconic的目录位置

  • innodb_rollback_segments: 回滚段的个数，默认128

9. 参考文章

  1. 《MySQL是怎样运行的–从根儿上理解MySQL》

  2. 图文结合带你搞定MySQL日志之Undo log(回滚日志)

小余哥xiaoyouge

分享一些技术教程与实践，以及日常踩坑记录。