开发者社区> 玄惭> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

ibdata1文件持续增加的问题定位

简介:
+关注继续查看

用户的ibdata1文件持续增加:

Innodb的表有两种存放方式:

第一种共享表空间方式:所有表的索引,数据统一存放在一个共享表空间中,这样会导致共享表空间的空间迅速增长,同时空间回收困难;

第二种独占表空间方式:就是RDS目前采用 的,也就是一张表一个表空间,表中的索引和数据存放在自己独立的表空间中,空间能够比较容易的回收;

无论是独占还是共享表空间,innodb都会有系统共享表空间(ibdata1),该系统表空间主要用于存储数据字典,undo entry,insert buffer,doublewrite buffer,

该系统表空间的增加通常的原因有如下:

a.长时间没有提交事务,同时数据库中有大量的更新,插入,删除 ,导致innodb创建大量的undo来维护一致性读:可以通过show engine innodb status\G查看active的事务:

SHOW ENGINE INNODB STATUS\G

—TRANSACTION 36E, ACTIVE 1256288 sec

MySQL thread id 42, OS thread handle 0x7f8baaccc700, query id 7900290 localhost root

show engine innodb status

Trx read view will not see trx with id >= 36F, sees < 36F

b.mysql 5.1中undo的purge是和master thread 共用一个线程,所以发现show engine inndob status\G中的histtory length过长,则可能的purge的速度到达了瓶颈,

所以在mysql 5.5将undo的purge独立出来,可以设置undo purge的线程个数:

| innodb_purge_threads    | 0     |

| innodb_max_purge_lag    | 0     |

| innodb_max_purge_size   | 0     |

| innodb_purge_batch_size | 20    |

如何查看ibdata1中的文件组建?

开源社区提供了一个工具:innodb_space可以清晰地分析出ibdata1的组成(该工具需要bindata环境)

innodb_space -f /tmp/ibdata1 space-page-type-summary

type                count       percent     description

UNDO_LOG            4430725     80.61       Undo log            

ALLOCATED           1035701     18.84       Freshly allocated

INODE               28348       0.52        File segment inode

INDEX               722         0.01        B+Tree index

IBUF_BITMAP         334         0.01        Insert buffer bitmap

XDES                333         0.01        Extent descriptor

IBUF_FREE_LIST      152         0.00        Insert buffer free list

SYS                 3           0.00        System internal

TRX_SYS             1           0.00        Transaction system header

FSP_HDR             1           0.00        File space header

可以看到ibdata1文件中大量的都是undo_log,在定位到其中的文件组成后,我们可以采取以下方案:

建议用户将版本从5.1升级到5.5,5.5中有独立的purge线程可以很快的回收掉undo log,迁移的过程中由于是采用逻辑迁移,会重建ibdata1文件降低空间使用;

在5.6中可以单独设置undo tablespace文件,避免与ibdata1混用在一起。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
MySQL 千万数据量深分页优化, 拒绝线上故障!
MySQL 千万数据量深分页优化, 拒绝线上故障!
0 0
ADBPG&Greenplum成本优化之磁盘水位管理
在核心技术自主可控的大环境下,政企行业客户都在纷纷尝试使用国产数据库或开源数据库,尤其在数据仓库OLAP领域的步伐更快,Greenplum的应用越来越广泛,阿里云ADB PG的市场机会也越来越多。今年阿里云使用ADB PG帮助很多客户升级了核心数仓。我们发现,客户往往比较关注使用云原生数仓的成本。究竟如何帮助客户节约成本,便值得我们去探索和落地。本文系统性探讨一下如何帮助客户优化MPP数据库的成本。
0 0
报错日志(长期更新)
报错日志(长期更新)
0 0
不再担心日志文件过大:通用日志滚动脚本
log_rotater.zip #!/bin/sh # https://github.com/eyjian/mooon/blob/master/mooon/shell/log_rotater.
423 0
一个清理和查询都要兼顾的简单方案
最近和开发应用的同学在讨论一个需求,目前他们碰到了一些性能问题,想让我来看看是否能够从数据库的角度有一些解决方案。 假设表为消费记录,简称service_details,这是一个普通表,目前这个表数据量很大,需要定期去删除一些过期的数据,至于过期的标准先暂时按照两个星期来算。
568 0
相同更改数据量的前提下,单次COMMIT和多次COMMIT对日志空间浪费的影响对比
LGWR进程按照顺序写在线日志,中间不会跳跃,而且LGWR进程不会在同一个日志快写2次,即使一次写入的日志快只占几个字节,下次不会再用了,这就造成日志空间的浪费。
555 0
记一次数据库重启后归档急剧增加的问题
在本地的环境中测试外部表的性能,由于空间有限,不一会儿归档的空间就爆了。然后文件貌似出现了系统级的问题,刚刚rm掉的归档日志文件。隔了几秒钟再ls,就出现了。
975 0
+关注
玄惭
RDS DBA
文章
问答
文章排行榜
最热
最新
相关电子书
更多
美团crash监控分析系统优化之路
立即下载
美团 crash 监控分析系统优化之路:crash 率从千分位到万分位
立即下载
重新出发:阿里云数据库开源整体策略
立即下载