数据库内核月报 - 2014 / 11

MySQL · 5.7特性 · 在线Truncate undo log 表空间

背景

Innodb使用undo log来实现MVCC,这意味着如果一个很老的事务长时间不提交,那么新产生的undo log都无法被及时清理掉。在MySQL 5.5及之前版本中,undo log是存储在ibdata中。从5.6开始可以使用独立的undo log表空间来存储undo。但是直到5.6,一旦undo log膨胀,依然没有任何办法为其 “减肥”。因此我们经常看到ibdata被膨胀到几十上百G。

改进

在MySQL5.7.5版本中终于增加了这个众望所归的功能,实现了在线truncate undo log的功能。对应的changeling entry如下:

InnoDB: You can now truncate undo logs that reside in undo tablespaces. This feature is enabled using the innodb_undo_log_truncate configuration option. For more information, see Truncating Undo Logs That Reside in Undo Tablespaces. 在能够使用该特性之前,需要先打开独立undo表空间,注意现在只能在install db的时候才能开启,因为在初始化阶段是写死占用了最小的几个space id的。这种实现方式。。。只能无限吐槽了。

有几个参数控制undo tablespace:

innodb_undo_directory:undo文件的存储目录。 innodb_undo_tablespaces:undo tablespace的个数,实现在线truncate undo,需要大于等于2,因为在truncate一个undo log文件时,要保证另外一个是可用的,这样就无需停止业务了。 innodb_undo_logs:undo回滚段的数量需要大于34。原因是1~32个回滚段会被临时表占用(5.7针对临时表做了大量优化),第33、34分配给undospace1 和undospace2。 这里有个比较有意思的问题,由于undo 回滚段总是从第一个undospace分配,如果每次从1开始,每次重启递增innodb_undo_logs,所有的回滚段都会被分配到第一个undo space,在truncate第一个undo space时,将无可用的undo回滚分配给正常的用户事务。

innodb_purge_rseg_truncate_frequency:用于控制purge回滚段的频度。 Innodb Purge操作的协调线程每隔这么多次purge事务分发后,就会触发一次History purge,并检查当前的undo log 表空间状态是否会触发truncate。 innodb_max_undo_log_size:控制最大undo tablespace文件的大小,超过这个阀值时才会去尝试truncate。truncate后的大小默认为10M。 innodb_undo_log_truncate:用于打开/关闭undo log 在线truncate特性,可动态调整。

undo log 的truncate操作由purge 协调线程发起,在truncate 某个undo log 表空间的过程中,保证有一个可用的undo log tablespace能提供给用户使用,从而实现所谓的在线truncate。

当选定一个需要truncate的undo log space时,需要检查其是否是可释放的,也就是说是否还有活跃的事务可能访问其中的回滚段。如果没有,就将该tablespace中的回滚段设置为不可分配,然后对undo log space文件进行truncate,并重新初始化到10M,初始化文件头等一系列操作。

这里引入了比较有意思的方法来保证truncate的原子性,即在开始truncate时,创建一个独立的文件,命名为undo__trunc.log,在做完truncate操作后,删除文件。如果在中间发生crash,崩溃恢复时发现该文件,会继续完成truncate操作。

更具体的参考WL#6965 及对应补丁Rev:8615