数据库内核月报 - 2019 / 05

MySQL · 引擎特性 · 通过 SQL 管理 UNDO TABLESPACE

前言

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:

 mysql> SELECT * FROM  INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE ROW_FORMAT = 'Undo'\G
*************************** 1. row ***************************
SPACE: 4294967279
NAME: innodb_undo_001
FLAG: 0
ROW_FORMAT: Undo
PAGE_SIZE: 16384
ZIP_PAGE_SIZE: 0
SPACE_TYPE: Undo
FS_BLOCK_SIZE: 0
FILE_SIZE: 0
ALLOCATED_SIZE: 0
SERVER_VERSION: 8.0.15
SPACE_VERSION: 1
ENCRYPTION: N
STATE: active
*************************** 2. row ***************************
SPACE: 4294967278
NAME: innodb_undo_002
FLAG: 0
ROW_FORMAT: Undo
PAGE_SIZE: 16384
ZIP_PAGE_SIZE: 0
SPACE_TYPE: Undo
FS_BLOCK_SIZE: 0
FILE_SIZE: 0
ALLOCATED_SIZE: 0
SERVER_VERSION: 8.0.15
SPACE_VERSION: 1
ENCRYPTION: N
STATE: active
2 rows in set (0.00 sec)

mysql> SHOW GLOBAL STATUS LIKE '%UNDO_TABLESPACE%';
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| Innodb_undo_tablespaces_total    | 2     |
| Innodb_undo_tablespaces_implicit | 2     |
| Innodb_undo_tablespaces_explicit | 0     |
| Innodb_undo_tablespaces_active   | 2     |
+----------------------------------+-------+
4 rows in set (0.00 sec)

创建新的undo space

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

  mysql> CREATE UNDO TABLESPACE myundo ADD DATAFILE 'myundo.ibd';
  ERROR 3121 (HY000): The ADD DATAFILE filepath must end with '.ibu'.

  mysql> CREATE UNDO TABLESPACE myundo ADD DATAFILE 'myundo.ibu';
  Query OK, 0 rows affected (0.26 sec)

  mysql> SELECT * FROM  INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE ROW_FORMAT = 'Undo' and NAME = 'myundo'\G
  *************************** 1. row ***************************
  SPACE: 4294967277
  NAME: myundo
  FLAG: 0
  ROW_FORMAT: Undo
  PAGE_SIZE: 16384
  ZIP_PAGE_SIZE: 0
  SPACE_TYPE: Undo
  FS_BLOCK_SIZE: 0
  FILE_SIZE: 0
  ALLOCATED_SIZE: 0
  SERVER_VERSION: 8.0.15
  SPACE_VERSION: 1
  ENCRYPTION: N
  STATE: active                       --> 此时状态为active
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状态之后,事务就不会从其中分配回滚段。

mysql> ALTER UNDO TABLESPACE myundo SET INACTIVE;
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状态

  mysql> DROP UNDO TABLESPACE myundo;
  ERROR 1529 (HY000): Failed to drop UNDO TABLESPACE myundo

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

  mysql> SELECT * FROM  INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE ROW_FORMAT = 'Undo' and Name = 'myundo'\G
  *************************** 1. row ***************************
  SPACE: 4294967150
  NAME: myundo
  FLAG: 0
  ROW_FORMAT: Undo
  PAGE_SIZE: 16384
  ZIP_PAGE_SIZE: 0
  SPACE_TYPE: Undo
  FS_BLOCK_SIZE: 0
  FILE_SIZE: 0
  ALLOCATED_SIZE: 0
  SERVER_VERSION: 8.0.15
  SPACE_VERSION: 1
  ENCRYPTION: N
  STATE: empty     --> 此时undo space内没有任何Undo log, 已经是empty可删除状态
  1 row in set (0.00 sec)

  mysql> DROP UNDO TABLESPACE myundo;
  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表空间的一些新变化