Innodb独立的undo tablespace
在MySQL5.6中开始支持把undo log分离到独立的表空间,并放到单独的文件目录下;这给我们部署不同IO类型的文件位置带来便利,对于并发写入型负载,我们可以把undo文件部署到单独的高速存储设备上.
MySQL从8.0开始undo 表空间管理已经发生了改变,在5.7版本中一旦MySQL初始化以后,就不能再改变undo表空间了,所以我们在5.7版本中都是在初始化的时候对undo表空间进行一些设置,类似这样:在my.cnf文件中加入innodb_undo_directory= /data/mysql/undologs 和 innodb_undo_tablespaces=5 这两个参数,之所以这么改,是因为我们想把undo表空单独从系统表空间idbdata中分离出来,这样就可以消除因undo的问题造成对ibdata系统表空间的影响,所以上面的参数配置在5.7版本中是我们对MySQL初始化做的一个常规的最佳实践设置,如果不设置,那么在5.7版本中,undo还是默认会放在ibdata中。
从MySQL8.0版本开始,MySQL默认对undo进行了分离操作,也就是说,不需要在初始化中手动配置参数,默认会在datadir目录下生成两个10兆大小的undo表空间文件undo_001 和 undo002 并且可以在线的增加和删除undo表空间文件进行动态扩容和收缩,这在之前的版本都是不被准许的,MySQL也在越做越优,相信以后会更加智能和全面。
1.使用
关于MySQL undo表空间我们需要掌握的知识如下:在线增加删除undo ,在线查看undo表空间信息:
在线增加undo表空间:
官方文档原文描述为:Because undo logs can become large during long-running transactions, creating additional undo tablespaces can help prevent individual undo tablespaces from becoming too large. As of MySQL 8.0.14, additional undo tablespaces can be created at runtime using CREATE UNDO TABLESPACE syntax.
CREATE UNDO TABLESPACE tablespace_name ADD DATAFILE ‘file_name.ibu’;
The undo tablespace file name must have an .ibu extension. It is not permitted to specify a relative path when defining the undo tablespace file name. A fully qualified path is permitted, but the path must be known to InnoDB. Known paths are those defined by the innodb_directories variable. Unique undo tablespace file names are recommended to avoid potential file name conflicts when moving or cloning data.
————————————————
有几个参数来控制该行为
#innodb_undo_tablespaces
用于设定创建的undo表空间的个数,在Install db时初始化后,就再也不能被改动了;
默认值为0,表示不独立设置undo的tablespace,默认记录到ibdata中;否则,则在undo目录下创建这么多个undo文件,例如假定设置该值为16,那么就会创建命名为undo001~undo016的undo tablespace文件,每个文件的默认大小为10M
修改该值可能会导致Innodb无法完成初始化;
#innodb_undo_logs
用于表示回滚段的个数(早期版本的命名为
innodb_rollback_segments
),该变量可以动态调整,但是物理上的回滚段不会减少,只是会控制用到的回滚段的个数;默认为128个回滚段
#innodb_undo_directory
当开启独立undo表空间时,指定undo文件存放的目录
如果我们想转移undo文件的位置,只需要修改下该配置,并将undo文件拷贝过去就可以了。
B. Yes. Shut down, copy the UNDO tablespaces to the new location, and change the
innodb_undo_directory value in your my.cnf.
innodb_undo_log_truncate
mysql> show variables like '%truncate%';
+--------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------+-------+
| innodb_purge_rseg_truncate_frequency | 128 |
| innodb_undo_log_truncate | ON |
+--------------------------------------+-------+
2 rows in set, 1 warning (0.00 sec)mysql>
set global innodb_undo_log_truncate=on开启truncate功能,innodb_max_undo_log_size为undo表空间文件的阈值,默认1G,超过改值,会自动进行truncate。如果不开启truncate则导致undo表空间文件不断增大。
被选中删除的undo文件,对应的回滚段标记为inactive,purge回收不再使用的回滚段,完成后进行truncate,恢复到10M大小,回滚段再次标记为active。
在线删除undo表空间
ALTER UNDO TABLESPACE tablespace_name SET INACTIVE;
DROP UNDO TABLESPACE tablespace_name;
需要两个步骤,先设置为inactive状态,然后再去删除。
undo表空间的查询
8.0版本中,我们查询undo如下
SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES
WHERE FILE_TYPE LIKE ‘UNDO LOG’;
SELECT NAME, STATE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
WHERE NAME LIKE tablespace_name;
也可通过下面命令查看一下undo的相关信息:
mysql> SHOW STATUS LIKE ‘Innodb_undo_tablespaces%’;
±---------------------------------±------+
| Variable_name | Value |
±---------------------------------±------+
| Innodb_undo_tablespaces_total | 2 |
| Innodb_undo_tablespaces_implicit | 2 |
| Innodb_undo_tablespaces_explicit | 0 |
| Innodb_undo_tablespaces_active | 2 |
±---------------------------------±------+
相对来说MySQL8.0版本对undo的管理已经比以前好多了,可以在线增加,删除,也可以随时查看undo的一些信息,更多的undo表空间意味着并发事务可以尽可能的使用单独的回滚段来减少相同资源的争用,相信以后的版本会越来越优秀,我们将拭目以待。
————————————————
版权声明:本文为CSDN博主「何天啸」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_29147589/article/details/113591973