暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

推荐 | MySQL的ibdata1是个啥,为啥越来越大,怎么缩小?

681

同事的一个问题:

MySQL的ibdata1文件越来越大,这是为啥?

回答这个问题,首先要整明白ibdata1文件是个嘛?

ibdata1是一个用来构建innodb系统表空间的文件,这个文件包含了innodb表的元数据、undo日志、修改buffer和双写buffer。
当在MySQL中对InnoDB表进行更改时,这些更改首先存储在InnoDB日志缓冲区的内存中,然后写入通常称为重做日志(redo logs)的InnoDB日志文件中。
这里放张图
随着数据库的使用,ibdata1文件会越来越大,innodb_autoextend_increment选项则指定了该文件每次自动增长的大小,默认是8M.
熟悉Oracle的亲,可以把ibdata理解成redo日志。
my.cnf中的参数设置形式:
innodb_data_file_path = ibdata1:256M;ibdata2:128M:autoextend

什么原因导致ibdata1越来越大?

上文也说了,ibdata1存放innodb表的元数据、undo日志、修改buffer和双写buffer,是MYSQL的最主要的数据,随着数据库越来越大,表也会越来越大。
尤其是innodb_file_per_table参数未开启的话,新创建表的数据和索引会存在系统表空间中,增加更加更快。

该如何处理呢?

业务数据使用独享表空间,将不用的业务表空间分别单独存放。
MySQL开启独享表空间的参数是Innodb_file_per_table,会为每个Innodb表创建一个.ibd的文件;这样ibdata1文件便不会增长那么快了。

没开启独享表空间Innodb_file_per_table,怎么减小ibdata的大小?

两个步骤:
1. 初始参数中修改innodb_data_file_path=1,保证业务数据被单独存放。
举例:innodb_data_file_path = ibdata1:32M;ibdata2:16M:autoextend
2. 使用mysqldump做下数据的导出和导入
步骤2实操如下:
1) 导出数据库中所有数据
# mysqldump -uroot -p --socket=/tmp/mysql.sock --single-transaction --master-data=2 --all-databases -E -R --triggers --set-gtid-purged=off > /tmp/all-database.dump
2) 删除数据库中数据
mysql> drop database dbname;
3) 停止MySQL
# /etc/init.d/mysqld stop
#mysqladmin -uroot -p shutdown
4) 删除ibdata1文件(移动到/tmp下)
# mv /var/lib/mysql/ibdata1 /tmp
# mv /var/lib/mysql/ib_logfile0 /tmp
# mv /var/lib/mysql/ib_logfile1 /tmp
5) my.cnf设定
# vi /etc/my.cnf
开启独享表空间,并指定ibdata1大小为256M,ibdata2大小128M,自动扩张。
innodb_file_per_table = 1
innodb_data_home_dir = /mysqldata/data
innodb_data_file_path = ibdata1:256M;ibdata2:128M:autoextend
6) 启动MySQL
# /etc/init.d/mysqld start
或者
# mysqld_safe --defaults-file=/etc/my.cnf --user=mysql &
7) 导入数据
# mysql -u root -p < /tmp/all-database.dump
8) 搞定
 
再问:
使用mysqldump缩小ibdata时,mysqldump导出导入太慢;
如何减少业务中断时间?
 
回答:充分利用主从架构来减少业务中断时长,怎么做?
 

步骤如下:

1. 主库mysqldump出导出文件,并scp到从库;

2. 从库做逻辑恢复,并使用gtid追平主库数据(注意此刻的从库已经修改了innodb_file_per_table = 1和innodb_data_file_path = ibdata1:256M;ibdata2:128M:autoextend)

3. 为保险起见,可找个业务空闲窗口,切换下高可用至从库(此刻的从库变为新主),并对外恢复业务数据访问

4. 原主做mysqldump恢复,并追平新主数据,此刻原主为新从

5. 搞定。

全文完。

Enjoy MySQL :)

关于 RadonDB

RadonDB开源社区 是一个面向云原生、容器化的数据库开源社区。为数据库技术爱好者提供围绕主流开源数据库(MySQL、PostgreSQL、Redis、MongoDB、ClickHouse 等)的技术分享平台,并提供企业级 RadonDB 开源产品及服务。

目前 RadonDB 开源数据库系列产品已被 光大银行、浦发硅谷银行、哈密银行、泰康保险、太平保险、安盛保险、阳光保险、百年人寿、安吉物流、安畅物流、蓝月亮、天财商龙、罗克佳华、升哲科技、无锡汇跑体育、北京电信、江苏交通控股、四川航空、昆明航空、国控生物 等上千家企业及社区用户采用。

RadonDB 可基于云平台与 Kubernetes 容器平台交付,不仅提供覆盖多场景的数据库产品解决方案,而且提供专业的集群管理和自动化运维能力,主要功能特性包括:高可用主从切换、数据强一致性、读写分离、一键安装部署、多维指标监控&告警、弹性扩容&缩容、横向自由扩展、自动备份&恢复、同城多活、异地灾备 等。RadonDB 仅需企业及社区用户专注于业务层逻辑开发,无需关注集群高可用选型、管理和运维等复杂问题,帮助企业及社区用户大幅度提升业务开发与价值创新的效率!

GitHub:

https://github.com/radondb


微信群: 请搜索添加群助手微信号 radondb


文章转载自RadonDB 开源社区,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论