MySQL8.0 Undo Tablespace管理详解

1. undo 基础概念

默认至少初始化2个undo表空间,最大支持127个undo表空间,默认表空间名称为undo_001,undo_002
8.0.14 之后undo表空间支持在线增加,及在线删除

create undo tablespace/drop undo tablespace
- 不支持指定相对路径,只支持绝对路径,且必须是innodb_directories参数定义可识别的路径或默认的数据目录下
- 动态创建的undo表空间必须以.ibu结尾

8.0.23 之前undo表空间初始大小依赖innodb_page_size的值配置,默认16k,初始文件大小为10m,8.0.23 之后undo表空间初始大小为16m,默认扩展大小单位为16m

2. undo 相关参数

2.1 参数含义

show variables like '%undo%';
+--------------------------+------------+
| variable_name            | value      |
+--------------------------+------------+
| innodb_max_undo_log_size | 8589934592 |   
| innodb_undo_directory    | ./         |  
| innodb_undo_log_encrypt  | off        |
| innodb_undo_log_truncate | on         |
| innodb_undo_tablespaces  | 2          |
+--------------------------+------------+

show variables like '%truncate%';
+--------------------------------------+-------+
| variable_name                        | value |
+--------------------------------------+-------+
| innodb_purge_rseg_truncate_frequency | 128   |
| innodb_undo_log_truncate             | on    |
+--------------------------------------+-------+

show variables like '%segment%';
+-------------------------------+-----------+
| variable_name                 | value     |
+-------------------------------+-----------+
| innodb_rollback_segments      | 128       |
| innodb_segment_reserve_factor | 12.500000 |
+-------------------------------+-----------+

innodb_undo_log_truncate			-- 控制是否自动做undo的truncate收缩操作,默认为on,只有为on时,下面2个参数才生效
	innodb_max_undo_log_size		-- 控制undo做truncate收缩操作的阈值,当undo达到该值时才出发收缩操作
	innodb_purge_rseg_truncate_frequency 
		-- batch undo清理的次数,默认最大值128,也就是128次后才会触发一次undo的truncate,而每次清理的undo page由innodb_purge_batch_size参数决定,innodb_purge_batch_size默认为300,也就是300*128个undo小批次清理后才会触发undo表空间的truncate(也就是undo表空间的收缩)操作

innodb_undo_tablespaces 		  -- 控制生成的undo表空间的数量,默认2个,在8.0对该参数做了废弃,但并未提供其他参数控制undo数量,当前依旧可以使用该参数做undo表空间数量配置,通常建议配置为3(手工收缩undo时需要至少3个undo表空间)

innodb_rollback_segments			-- undo表空间回滚段的数量,默认为最大值128

3. undo 表空间运维

3.1 查看undo的基本信息

-- 可以查看到undo的表空间名称/文件路径/初始大小/扩展大小/磁盘文件大小/可用空间及是否启用的状态等
select t1.space as space_id,
       t1.name as tablespace_name,
       t2.file_name,
       round(t2.initial_size / 1024 / 1024, 2) as "initial_size(m)",
       round(t2.autoextend_size / 1024 / 1024, 2) as "autoextend_size(m)",
       round(t1.file_size / 1024 / 1024, 2) as "file_size_disk(m)",
       round(t2.data_free / 1024 / 1024, 2) as "data_free(m)",
       t2.status,
       t1.state
  from information_schema.innodb_tablespaces t1,
       information_schema.files              t2
 where t1.space = t2.file_id
   and t1.row_format = 'undo';

3.2 添加/active/inactive/删除undo表空间

create undo tablespace

用来创建新的undo 表空间

drop undo tablespace

用来删除undo 表空间

alter undo tablespace xxxx set active

用来激活undo的使用

alter undo tablespace xxxx set inactive

用来关闭undo的使用(关闭后的undo才可删除)

-- 创建一个新的undo表空间
create undo tablespace undo_004 add datafile 'undo_004.ibu';

-- 可以用前面的命令查看创建后的状态

-- 可以将已有的undo表示为inactive(也可理解为undo表空间收缩)
-- ps:设置为inactive的表空间的state为empty,表示这个表空间不包含任何事务回滚数据,且表空间也收缩为默认大小
alter undo tablespace undo_003 set inactive;

-- 可以将inactive的undo转为active
alter undo tablespace innodb_undo_001 set active;

-- 可以将inactive的undo表空间进行删除
-- ps:默认以innodb_开头初始化的undo表空间不可被删除
drop undo tablespace innodb_undo_001;
error: 3119 (42000): innodb: tablespace names starting with `innodb_` are reserved.

-- 非系统默认的undo在inactive后可被删除
alter undo tablespace undo_003 set active;
query ok, 0 rows affected (0.0030 sec)

3.3 影响undo inactive(truncate)性能的因素

undo 表空间的大小
undo 表空间的数量
undo logs的数量(实际insert/update/delete这类事务回滚段的数据量)
磁盘io的能力/当前系统的负载
是否存在长事务在使用该undo表空间

ps:通常对表空间做收缩前最简单避免性能的方式是提前创建一个undo表空间,收缩完后再删除或一直保留均可

4. undo 的监控

4.1 undo的监控指标

-- 可以使用以下命令开启对undo的监控采集
set global innodb_monitor_enable=module_undo;
set global innodb_monitor_enable=module_purge;

-- 使用该命令查看undo truncate的次数及耗时等信息
select name,subsystem,count,status,comment 
from information_schema.innodb_metrics 
where name like '%truncate%';

4.2 undo的状态值

show status like 'innodb_undo_tablespaces%';
+----------------------------------+-------+
| variable_name                    | value |
+----------------------------------+-------+
| innodb_undo_tablespaces_total    | 4     |  -- 总共的undo表空间数量
| innodb_undo_tablespaces_implicit | 2     |  -- 这里implicit其实表示的初始化创建的默认undo表空间个数,这种undo不可被删除
| innodb_undo_tablespaces_explicit | 2     |  -- 这里explicit其实表示手工显式创建的undo表空间的个数
| innodb_undo_tablespaces_active   | 4     |	-- 表示处于active的undo表空间的个数,可以看到当前和total一样,说明都在使用
+----------------------------------+-------+

5. undo 大小对并发数的限制

5.1 undo 记录的类型及大小

undo logs包含的是事务最后一次修改的聚簇索引记录(mysql是聚簇索引表,也就是包含了一行完整的记录)

当innodb_page_size 为16kb默认值时,undo 的slot槽为1024个

16kb*1024/16=1024个槽

undo一共有以下4中日志类型

insert 用户自定义的表
update and delete 用户自定义的表
insert 自定义的临时表
update and delete 自定义的临时表

5.2 undo各场景下支持的读写并发

5.2.1 场景1: 每个事务都执行一个insert or update(delete)

并发公式: (innodb_page_size / 16) * innodb_rollback_segments * number of undo tablespaces

select 16*1024/16*128*2;
+------------------+
| 16*1024/16*128*2 |
+------------------+
|      262144.0000 |
+------------------+

5.2.2 场景2: 每个事务都执行一个insert and update(delete)

并发公式:(innodb_page_size / 16 / 2) * innodb_rollback_segments * number of undo tablespaces

select 16*1024/16/2*128*2;
+--------------------+
| 16*1024/16/2*128*2 |
+--------------------+
|    131072.00000000 |
+--------------------+

5.2.3 场景3: 每个事务都执行一个insert or update(delete) 到临时表

并发公式: (innodb_page_size / 16) * innodb_rollback_segments

select 16*1024/16*128;
+----------------+
| 16*1024/16*128 |
+----------------+
|    131072.0000 |
+----------------+

5.2.4 场景4: 每个事务都执行一个insert and update(delete) 到临时表

并发公式:(innodb_page_size / 16 / 2) * innodb_rollback_segments

select 16*1024/16/2*128;
+------------------+
| 16*1024/16/2*128 |
+------------------+
|   65536.00000000 |
+------------------+

6. 参考链接

https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-logs.html
https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html

到此这篇关于mysql8.0 undo tablespace管理详解的文章就介绍到这了,更多相关mysql8.0 undo tablespace内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！

声明：如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。