5分钟了解MySQL5.7的undo log在线收缩新特性

Part1:写在最前

在MysQL5.6版本中,可以把undo log 回滚日志分离到一个单独的表空间里;其缺点是不能回收空间大小,until MysQL5.7,but MariadDB10.1暂不支持。

本文介绍并演示MysQL5.7是如何在线收缩undo log的。

undo log日志是保存在共享表空间ibdata1文件中的,随着数据库的运行时间的不断增长,ibdata1文件会越来越大,在以往的MySQL数据库版本中,如果我们想要回收ibdata1文件所占空间,会非常的复杂和困难,必须先将mysqldump -A全库导出,然后删掉data目录,再重新对数据库进行初始化,最后导入全库备份,方可实现ibdata1的回收。

MySQL全库备份方式可参考:

http://suifu.blog.51cto.com/9167728/1758022

MySQL5.7的安装方式可参考:

http://suifu.blog.51cto.com/9167728/1855415

首先我们需要调整my.cnf参数

innodb_undo_directory=/data/undolog

innodb_undo_tablespaces=4

innodb_undo_logs=128

innodb_max_undo_log_size=1G

innodb_purge_rseg_truncate_frequency

innodb_undo_log_truncate=1

Warning:警告

其中innodb_undo_directory参数要在数据库初始化时就需要写入my.cnf,否则会报如下错误:

Expected to open 4 undo tablespaces but was able to find only 0 undo tablespaces. Set the innodb_undo_tablespaces parameter to the correct value and retry. Suggested value is 0

Part2:MySQL5.7在线回收undolog

首先对一张100万行的表进行整表更新

mysql> show variables like ‘innodb_undo%‘;

+--------------------------+---------------+

| Variable_name            | Value         |

+--------------------------+---------------+

| innodb_undo_directory    | /data/undolog |

| innodb_undo_log_truncate | ON            |

| innodb_undo_logs         | 128           |

| innodb_undo_tablespaces  | 4             |

+--------------------------+---------------+

rows in set (0.00 sec)

mysql> update helei set c1=1;

Query OK, 1000000 rows affected (45.48 sec)

Rows matched: 1000000  Changed: 1000000  Warnings: 0

mysql> update helei set c2=222;

Query OK, 1000000 rows affected (43.25 sec)

Rows matched: 1000000  Changed: 1000000  Warnings: 0

mysql> update helei set c4=‘heleiheleiheleiheleihel‘;

Query OK, 1000000 rows affected (10.28 sec)

Rows matched: 1000000  Changed: 1000000  Warnings: 0

②注意undolog的日志大小

[[email protected] undolog]# ls -lshrt

total 412M

128M -rw-r----- 1 mysql mysql 128M Sep 26 16:56 undo004

76M -rw-r----- 1 mysql mysql  76M Sep 26 16:56 undo003

136M -rw-r----- 1 mysql mysql 136M Sep 26 16:56 undo001

72M -rw-r----- 1 mysql mysql  72M Sep 26 16:56 undo002

③error.log日志

2016-09-26T23:51:06.062828Z 0 [Note] InnoDB: Truncating UNDO tablespace with space identifier 1

2016-09-26T23:51:06.159077Z 0 [Note] InnoDB: Completed truncate of UNDO tablespace with space identifier 1

2016-09-26T23:51:06.159101Z 0 [Note] InnoDB: Truncating UNDO tablespace with space identifier 2

2016-09-26T23:51:06.242355Z 0 [Note] InnoDB: Completed truncate of UNDO tablespace with space identifier 2

2016-09-26T23:51:06.242378Z 0 [Note] InnoDB: Truncating UNDO tablespace with space identifier 3

2016-09-26T23:51:06.313036Z 0 [Note] InnoDB: Completed truncate of UNDO tablespace with space identifier 3

2016-09-26T23:51:06.313060Z 0 [Note] InnoDB: Truncating UNDO tablespace with space identifier 4

2016-09-26T23:51:06.403003Z 0 [Note] InnoDB: Completed truncate of UNDO tablespace with space identifier 4

④观察物理文件

[[email protected] undolog]# ls -lshrt

total 168M

76M -rw-r----- 1 mysql mysql 76M Sep 26 16:56 undo003

10M -rw-r----- 1 mysql mysql 10M Sep 26 16:56 undo001

10M -rw-r----- 1 mysql mysql 10M Sep 26 16:56 undo004

72M -rw-r----- 1 mysql mysql 72M Sep 26 16:56 undo002

可以看到超过100M设定值的undo日志已经回收,默认为10M,undo log空间得以释放

Part3:意义

该功能降低了磁盘的使用率,并且可以提高诸如Xtrabackup这类物理备份软件的备份速度。

时间: 2024-08-25 12:01:26

5分钟了解MySQL5.7的undo log在线收缩新特性的相关文章

TP3.2项目 MySQL5.7报错1055 group by新特性

TP3.2项目中本来使用的是mysql5.6进行开发,切换到5.7之后,突然发现原来的一些sql运行都报错,错误编码1055,错误信息和sql_mode中的"only_full_group_by"有关,到网上看了原因,说是mysql5.7中only_full_group_by这个模式是默认开启的 ,网上给了很多解决办法,因为我用的是WAMP集成环境,我的解决办法如下: 点击MySQL选择MySQL settings ->选择sql-mode->选择sql-none和sql-

总结一下,MariaDB 10(MySQL5.6企业版分支)的主要新特性

① 支持48核的CPU,而5.5支持24核的CPU ② 内存热数据持久化,我们知道当系统重启或者mysql进程重启后,Innodb的内存池里面的热数据全部清空,需要重新把磁盘的数据缓存进来,然后根据 LRU最近最少使用原则,把热数据保持在内存里,冷数据踢出到磁盘里.这个过程是缓慢的.5.6里改进了这一点,会自动把内存的热数据导出到磁盘里,这样 mysql重启后,会立即从磁盘里导入Innodb内存池,减少了与磁盘IO的交互. ③ 在线DDL功能.5.5版本里,修改表结构会导致锁表,例如用户进件会卡

MySQL5.7 可以回收(收缩)undo log回滚日志物理文件空间

undo log回滚日志是保存在共享表空间ibdata1文件里,随着业务的不停运转,ibdata1文件会越来越大,想要回收(收缩空间大小)极其困难和复杂, 必须先mysqldump -A全库的导出,然后删掉data目录,然后重新初始化安装,最后再把全库的SQL文件导入,采用这种方法进行ibdata1文件的回收. 在MySQL5.6里,可以把undo log回滚日志分离出去,到一个单独的表空间里,具体请参考:http://hcymysql.blog.51cto.com/5223301/973450

mysql5.6和mysql5.7分配undo回滚段的区别

1.mysql5.7中分为2类:临时表空间回滚段和普通回滚段. 2.mysql5.6中没有区分. As of MySQL 5.7.2, 32 undo logs are reserved for use by temporary tables and are hosted in the temporary table tablespace (ibtmp1). To allocate additional undo logs for data-modifying transactions that

浅析如何将undo log从tablespace分离

从MySQL5.6.3之后,MySQL支持将undo日志从tablespace(ibdataN)中独立开来放到单独的磁盘上.MySQL官方建议将undo放到ssd上,而把ibdata放在hd.(这里似乎有争论,国内某些大牛建议将顺序读写的log日志放在hdd) 比较重要的一个概念: 虽然undo log被分离出去了,但是其io处理还是在system tablespace内完成,所以定义上来讲还是算tablespace的.文档中原文如下: "Because these files handleI/

MySQL5.7新特性——在线收缩undo表空间

1. MySQL 5.5时代的undo log 在MySQL5.5以及之前,大家会发现随着数据库上线时间越来越长,ibdata1文件(即InnoDB的共享表空间,或者系统表空间)会越来越大,这会造成2个比较明显的问题: (1)磁盘剩余空间越来越小,到后期往往要加磁盘: (2)物理备份时间越来越长,备份文件也越来越大. 这是怎么回事呢? 原因除了数据量自然增长之外,在MySQL5.5以及之前,InnoDB的undo log也是存放在ibdata1里面的.一旦出现大事务,这个大事务所使用的undo

一分钟完成MySQL5.7安装部署

Part1:写在最前 MYSQL5.7.15是截止至本文撰写当日,mysql官网的最新社区版,mysql5.7的多项功能优化可以用激动人心来形容,嫌安装麻烦?没关系,跟着本文,带你1分钟搞定MySQL5.7.15数据库安装部署. Part2:仅仅安装就够了? 不,当然不够,MySQL5.7的多项功能特性更新,无法一一赘述,因此,我们先从和本文最相关的my.cnf,来解读一些MySQL5.7的部分新特性. 在之前我写过一篇MySQL5.6的新特性参数,诸如: innodb_buffer_pool_

MySQL的日志(二):事务日志(redo log和undo log)

本文目录:1.redo log 1.1 redo log和二进制日志的区别 1.2 redo log的基本概念 1.3 日志块(log block) 1.4 log group和redo log file 1.5 redo log的格式 1.6 日志刷盘的规则 1.7 数据页刷盘的规则及checkpoint 1.8 LSN超详细分析 1.9 InnoDB的恢复行为 1.10 和redo log相关的变量2.undo log 2.1 undo log的基本概念 2.2 undo log的存储方式

说说MySQL中的Redo log Undo log都在干啥

阅读目录(Content) 1 undo 1.1 undo是啥 1.2 undo参数 1.3 undo空间管理 2 redo 2.1 redo是啥 2.2 redo 参数 2.3 redo 空间管理 3 undo及redo如何记录事务 3.1 Undo + Redo事务的简化过程 3.2  IO影响 3.3 恢复 在数据库系统中,既有存放数据的文件,也有存放日志的文件.日志在内存中也是有缓存Log buffer,也有磁盘文件log file,本文主要描述存放日志的文件. MySQL中的日志文件,