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.7 ,才支持在线收缩。

innodb_undo_log_truncate参数设置为1,即开启在线回收(收缩)undo log日志文件,支持动态设置。
innodb_undo_tablespaces参数必须大于或等于2,即回收(收缩)一个undo log日志文件时,要保证另一个undo log是可用的。
innodb_undo_logs: undo回滚段的数量, 至少大于等于35,默认128。
innodb_max_undo_log_size:当超过这个阀值(默认是1G),会触发truncate回收(收缩)动作,truncate后空间缩小到10M。
innodb_purge_rseg_truncate_frequency:控制回收(收缩)undo log的频率。undo log空间在它的回滚段没有得到释放之前不会收缩,
想要增加释放回滚区间的频率,就得降低innodb_purge_rseg_truncate_frequency设定值。

验证过程:
对一张100万的sbtest表,进行全表更新4次,如:

然后你会发现undo log空间急速增长,如:

然后用sysbench做压力测试,让数据库运行起来,观察错误日志,就会自动把undo log空间给回收(收缩),如:

再通过观察物理文件,已经被回收了,默认10M大小。

总结:

这个功能出来以后,降低了磁盘空间使用率(当然,土豪随意),并且加快了xtrabackup热备份的速度。

时间: 2024-11-02 10:23:04

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

Log4net入门(回滚日志文件篇)

在上一篇Log4net(日志文件篇)中,我们使用"log4net.Appender.FileAppender"将日志信息输出到一个单一的文件中,随着应用程序的持续使用,该日志文件会越来越庞大,进而影响系统的性能.因此,有必要对日志文件按某种条件进行切分,要切分日志文件,我们可以使用"log4net.Appender.RollingFileAppender"输出源,使用该输出源我们可以按照文件大小或者日期对日志文件进行切分,下面我们分别描述之. 一.按文件大小切分日志

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文件所占空间,会非常的复杂和困难,必须先将

mysql中的事务隔离级别及可重复读读提交详细分析(mvcc多版本控制/undo log)

一.事物隔离级别 读未提交(read uncommitted)是指,一个事务还没提交时,它做的变更就能被别的事务看到.通俗理解,别人改数据的事务尚未提交,我在我的事务中也能读到. 读提交(read committed)是指,一个事务提交之后,它做的变更才会被其他事务看到.通俗理解,别人改数据的事务已经提交,我在我的事务中才能读到. 可重复读(repeatable read)是指,一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数据 是一致的.当然在可重复读隔离级别下,未提交变更对其他事

说说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中的日志文件,

【msql】redo and undo log

Innodb Crash Recovery InnoDB 有两块非常重要的日志,一个是undo log,另外一个是redo log,前者用来保证事务的原子性以及InnoDB的MVCC,后者用来保证事务的持久性.和大多数关系型数据库一样,InnoDB记录了对数据文件的物理更改,并保证总是日志先行,也就是所谓的WAL,即在持久化数据文件前,保证之前的redo日志已经写到磁盘 Crash Recovery是InnoDB引擎的一个特点,当故障发生,重新启服务后,会自动完成恢复操作,将数据库恢复到之前一个

InnoDB事务日志(redo log 和 undo log)详解

数据库通常借助日志来实现事务,常见的有undo log.redo log,undo/redo log都能保证事务特性,undolog实现事务原子性,redolog实现事务的持久性. 为了最大程度避免数据写入时io瓶颈带来的性能问题,MySQL采用了这样一种缓存机制:当query修改数据库内数据时,InnoDB先将该数据从磁盘读取到内存中,修改内存中的数据拷贝,并将该修改行为持久化到磁盘上的事务日志(先写redo log buffer,再定期批量写入),而不是每次都直接将修改过的数据记录到硬盘内,

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的存储方式

[转]undo log与redo log原理分析

数据库通常借助日志来实现事务,常见的有undo log.redo log,undo/redo log都能保证事务特性,这里主要是原子性和持久性,即事务相关的操作,要么全做,要么不做,并且修改的数据能得到持久化. 假设数据库在操作时,按如下约定记录日志: 1. 事务开始时,记录START T 2. 事务修改时,记录(T,x,v),说明事务T操作对象x,x的值为v 3. 事务结束时,记录COMMIT T undo log原理 undo log是把所有没有COMMIT的事务回滚到事务开始前的状态,系统

bin log、redo log、undo log和MVVC

logs innodb事务日志包括redo log和undo log.redo log是重做日志,提供前滚操作,undo log是回滚日志,提供回滚操作. undo log不是redo log的逆向过程,其实它们都算是用来恢复的日志: redo log通常是物理日志,记录的是数据页的物理修改,而不是某一行或某几行修改成怎样怎样,它用来恢复提交后的物理数据页(恢复数据页,且只能恢复到最后一次提交的位置).mysql中使用了大量缓存,缓存存在于内存中,修改操作时会直接修改内存,而不是立刻修改磁盘,当