前言

InnoDB的undo log从5.6版本开始可以存储到单独的tablespace文件中，在5.7版本支持了在线undo文件truncate，解决了长期以来的undo膨胀问题。而到了8.0版本，对Undo tablespace做了进一步的优化：在新版本中，我们可以拥有更多的回滚段(每个Undo tablespace可以有128个回滚段，而在之前的版本中所有tablespace的回滚段不允许超过128个)，减少了由于事务公用回滚段产生的锁冲突；可以在线动态的增删undo tablespace，使得undo的管理更加灵活。

在最近release的8.0.14版本中，开始支持SQL接口来创建，修改和删除 （undo space的管理不记录binlog）。可以预见未来将逐步废弃根据配置innodb_undo_tablespaces来创建undo tablespace, 通过SQL接口来创建undo tablespace将是唯一的接口。实际上在最新版本中已经将参数innodb_undo_tablespaces标记为deprecated状态，用户应尽量避免依赖该参数。

SQL语句

implict undo space

在安装实例时，会默认创建两个undo tablespace:

  1.  mysql> SELECT * FROM  INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE ROW_FORMAT = 'Undo'\G
  2. *************************** 1. row ***************************
  3. SPACE: 4294967279
  4. NAME: innodb_undo_001
  5. FLAG: 0
  6. ROW_FORMAT: Undo
  7. PAGE_SIZE: 16384
  8. ZIP_PAGE_SIZE: 0
  9. SPACE_TYPE: Undo
  10. FS_BLOCK_SIZE: 0
  11. FILE_SIZE: 0
  12. ALLOCATED_SIZE: 0
  13. SERVER_VERSION: 8.0.15
  14. SPACE_VERSION: 1
  15. ENCRYPTION: N
  16. STATE: active
  17. *************************** 2. row ***************************
  18. SPACE: 4294967278
  19. NAME: innodb_undo_002
  20. FLAG: 0
  21. ROW_FORMAT: Undo
  22. PAGE_SIZE: 16384
  23. ZIP_PAGE_SIZE: 0
  24. SPACE_TYPE: Undo
  25. FS_BLOCK_SIZE: 0
  26. FILE_SIZE: 0
  27. ALLOCATED_SIZE: 0
  28. SERVER_VERSION: 8.0.15
  29. SPACE_VERSION: 1
  30. ENCRYPTION: N
  31. STATE: active
  32. 2 rows in set (0.00 sec)
  34. mysql> SHOW GLOBAL STATUS LIKE '%UNDO_TABLESPACE%';
  35. +----------------------------------+-------+
  36. | Variable_name                    | Value |
  37. +----------------------------------+-------+
  38. | Innodb_undo_tablespaces_total    | 2     |
  39. | Innodb_undo_tablespaces_implicit | 2     |
  40. | Innodb_undo_tablespaces_explicit | 0     |
  41. | Innodb_undo_tablespaces_active   | 2     |
  42. +----------------------------------+-------+
  43. 4 rows in set (0.00 sec)

创建新的undo space

你可以通过如下语句来创建独立的undo tablespace， 文件后缀必须以ibu结尾。新创建的tablespace为active状态

  1.   mysql> CREATE UNDO TABLESPACE myundo ADD DATAFILE 'myundo.ibd';
  2.   ERROR 3121 (HY000): The ADD DATAFILE filepath must end with '.ibu'.
  4.   mysql> CREATE UNDO TABLESPACE myundo ADD DATAFILE 'myundo.ibu';
  5.   Query OK, 0 rows affected (0.26 sec)
  7.   mysql> SELECT * FROM  INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE ROW_FORMAT = 'Undo' and NAME = 'myundo'\G
  8.   *************************** 1. row ***************************
  9.   SPACE: 4294967277
  10.   NAME: myundo
  11.   FLAG: 0
  12.   ROW_FORMAT: Undo
  13.   PAGE_SIZE: 16384
  14.   ZIP_PAGE_SIZE: 0
  15.   SPACE_TYPE: Undo
  16.   FS_BLOCK_SIZE: 0
  17.   FILE_SIZE: 0
  18.   ALLOCATED_SIZE: 0
  19.   SERVER_VERSION: 8.0.15
  20.   SPACE_VERSION: 1
  21.   ENCRYPTION: N
  22.   STATE: active                       --> 此时状态为active
  23. 1 row in set (0.01 sec)

在创建undo space时，你可以使用绝对路径，也可以放在实例配置的undo目录下，但要注意一点:在崩溃恢复前undo space必须要能够被发现并打开，但这时候Innodb data dictionary还是处于不可用的状态，我们无法从其中获取准确的文件位置，只有–datadir, –innodb-home-directory, –innodb-undo-directory 和 –innodb-directories会被扫描掉，如果你放在其他地方，就可能造成找不到该tablespace, 导致实例数据不一致。

相关代码：

  • Server层接口类：Sql_cmd_create_undo_tablespace
  • 为undo tablespace预留的space id (但最多依然是127个undo tablespace, 每个space number会给一个范围内的space id, 默认512个id):
    • s_min_undo_space_id = 0xFFFFFFF0UL - 127 * 512
    • s_max_undo_space_id = 0xFFFFFFF0UL - 1
  • InnoDB入口函数: innodb_create_undo_tablespace
    • 获取下一个可用的space id: undo::get_next_available_space_num(), 先拿到空闲的space number，再分配一个可用的space id
    • srv_undo_tablespace_create: 创建undo space, 初始化回滚段并加入到全局事务系统中
    • 提交变更，持久化tablespace信息后，将其设置为active状态，此后事务可以从其中分配到回滚段

设置inactive

如果你不想使用某个Undo tablespace，可以将其设置为inactive状态， 但需要保证至少有连个active的undo tablespace, 这个限制的原因是：当一个undo tablespace正在被truncate时，至少有一个是可用的。

当被设置为Inactive状态之后，事务就不会从其中分配回滚段。

  1. mysql> ALTER UNDO TABLESPACE myundo SET INACTIVE;
  2. Query OK, 0 rows affected (0.01 sec)

相关代码：

  • server层接口类：Sql_cmd_alter_undo_tablespace
  • 在崩溃恢复data dicitonary提供服务后，需要将undo space状态更新到内存（apply_dd_undo_state()）
  • innodb_alter_undo_tablespace–> innodb_alter_undo_tablespace_active
    • 设置Undo space 为active状态，并修改dd元数据
  • innodb_alter_undo_tablespace –> innodb_alter_undo_tablespace_inactive
    • 当undo space状态为empty时，直接返回
    • 当undo space状态为active时，需要确保至少两个active的undo space才允许操作，否则返回错误
    • 设置dd state为inactive，并修改回滚段状态
    • 设置truncate frequency为1并唤醒purge线程, 这样purge线程会更频繁的去做purge操作，加快undo space的回收

删除undo space

在删除一个undo tablespace之前，首先要把undo tablespace设置为inactive状态

  1.   mysql> DROP UNDO TABLESPACE myundo;
  2.   ERROR 1529 (HY000): Failed to drop UNDO TABLESPACE myundo
  4.   mysql> ALTER UNDO TABLESPACE myundo SET INACTIVE;
  5.   Query OK, 0 rows affected (0.01 sec)
  7.   mysql> SELECT * FROM  INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE ROW_FORMAT = 'Undo' and Name = 'myundo'\G
  8.   *************************** 1. row ***************************
  9.   SPACE: 4294967150
  10.   NAME: myundo
  11.   FLAG: 0
  12.   ROW_FORMAT: Undo
  13.   PAGE_SIZE: 16384
  14.   ZIP_PAGE_SIZE: 0
  15.   SPACE_TYPE: Undo
  16.   FS_BLOCK_SIZE: 0
  17.   FILE_SIZE: 0
  18.   ALLOCATED_SIZE: 0
  19.   SERVER_VERSION: 8.0.15
  20.   SPACE_VERSION: 1
  21.   ENCRYPTION: N
  22.   STATE: empty     --> 此时undo space内没有任何Undo log， 已经是empty可删除状态
  23.   1 row in set (0.00 sec)
  25.   mysql> DROP UNDO TABLESPACE myundo;
  26.   Query OK, 0 rows affected (0.02 sec)

即使状态为inactive的，但要保证如下几点才能被删除：

  • 没有任何事务需要看到其中的老版本数据，也就是说所有在该事务之前开启的read view必须全部关闭
  • 所有使用该undo tablespace的事务必须全部提交或回滚掉
  • purge线程需要将其中的Undo log全部清理掉

如果undo tablespace非空，在drop时，会返回错误码HA_ERR_TABLESPACE_IS_NOT_EMPTY. 所以在设置为inactive到真正可以删除可能存在时间差，我们可以通过监控INFORMATION_SCHEMA.INNODB_TABLESPACES中的undo space状态是否为empty来判定是否可以删除。 Note:系统创建的Undo space不允许被删除

相关代码:

  • Server层接口类：Sql_cmd_drop_undo_tablespace
  • InnoDB 入口函数： innodb_drop_undo_tablespace
    • 当undo space状态不为emtpy时或者是系统创建的Undo space时，不允许删除
    • invalidate buffer pool中该space的page
    • 从内存中删除，记录ddl log
    • 事务提交后，执行post ddl (Log_DDL::replay_delete_space_log)
      • 真正物理删除文件
      • 标记对应的space num为未使用状态

undo truncation

当参数innodb_undo_log_truncate打开时，所有隐式和显式创建的Undo tablespace都会在满足一定条件时被purge线程truncate掉. 当参数关闭时，则只有将Undo tablespace设置为Inactive状态时才会去truncate tablespace。 因此如果你想自己控制undo truncation, 可以关闭参数，在监控undo tablespace的大小，通过SET INACTIVE触发truncation, 再通过SET ACTIVE激活undo space。

相关代码：

  • 由purge线程发起，入口函数:trx_purge_truncate_marked_undo()
  • 需要获取MDL锁，来保护space不被alter/drop
  • 通过flush_observer flush当前space的page
  • trx_purge_truncate_marked_undo_low
    • trx_undo_truncate_tablespace:
      • 为当前space分配一个新的space id: undo::use_next_space_id(space_num)
      • fil_replace_tablespace: 删除当前undo space，重建文件并设置为新的space id
      • 重新初始化回滚段和内存信息
      • 根据新的space id，将所有变更刷到磁盘
      • 如果是用户创建的undo space，将状态设置为empty，否则设置为active状态
      • 更新DD

为何需要新的space id ? 这是因为在删除重建文件的过程中我们没有做checkpoint,这时候如果crash掉，有些redo log可能需要修改一些已经不存在的page，导致崩溃恢复时候(ref: bug93170)

Reference

1. WL#9508: InnoDB: Support CREATE/ALTER/DROP UNDO TABLESPACE 2. WL#9507: InnoDB: Make the number of undo tablespaces and rollback segments dynamic 3. 主要代码 4. 官方文档 5. MySQL8.0 · 引擎特性 · 关于undo表空间的一些新变化