mysql 里的 ibdata1 文件

为什么 mysql 里的 ibdata1 文件不断的增长？

转自：http://linux.cn/article-5829-rss.html

mysql 里的 ibdata1 文件

ibdata1 file

我们在 Percona 支持栏目经常收到关于 MySQL 的 ibdata1 文件的这个问题。

当监控服务器发送一个关于 MySQL 服务器存储的报警时，恐慌就开始了 —— 就是说磁盘快要满了。

一番调查后你意识到大多数地盘空间被 InnoDB 的共享表空间 ibdata1 使用。而你已经启用了 innodb_file_per_table，所以问题是：

ibdata1存了什么？

当你启用了 innodb_file_per_table，表被存储在他们自己的表空间里，但是共享表空间仍然在存储其它的 InnoDB 内部数据：

数据字典，也就是 InnoDB 表的元数据
变更缓冲区
双写缓冲区
撤销日志

其中的一些在 Percona 服务器上可以被配置来避免增长过大的。例如你可以通过 innodb_ibuf_max_size 设置最大变更缓冲区，或设置 innodb_doublewrite_file 来将双写缓冲区存储到一个分离的文件。

MySQL 5.6 版中你也可以创建外部的撤销表空间，所以它们可以放到自己的文件来替代存储到 ibdata1。可以看看这个文档。

什么引起 ibdata1 增长迅速？

当 MySQL 出现问题通常我们需要执行的第一个命令是：

 
 
SHOW ENGINE INNODB STATUS/G

这将展示给我们一些很有价值的信息。我们从** TRANSACTION（事务）**部分开始检查，然后我们会发现这个：

 
 
---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

这是一个最常见的原因，一个14天前创建的相当老的事务。这个状态是活动的，这意味着 InnoDB 已经创建了一个数据的快照，所以需要在撤销日志中维护旧页面，以保障数据库的一致性视图，直到事务开始。如果你的数据库有大量的写入任务，那就意味着存储了大量的撤销页。

如果你找不到任何长时间运行的事务，你也可以监控INNODB STATUS 中的其他的变量，“History list length（历史记录列表长度）”展示了一些等待清除操作。这种情况下问题经常发生，因为清除线程（或者老版本的主线程）不能像这些记录进来的速度一样快地处理撤销。

我怎么检查什么被存储到了 ibdata1 里了？

很不幸，MySQL 不提供查看什么被存储到 ibdata1 共享表空间的信息，但是有两个工具将会很有帮助。第一个是马克·卡拉汉制作的一个修改版 innochecksum ，它发布在这个漏洞报告里。

它相当易于使用：

 
 
# ./innochecksum /var/lib/mysql/ibdata1
  
  0 bad checksum
  
  13 FIL_PAGE_INDEX
  
  19272 FIL_PAGE_UNDO_LOG
  
  230 FIL_PAGE_INODE
  
  1 FIL_PAGE_IBUF_FREE_LIST
  
  892 FIL_PAGE_TYPE_ALLOCATED
  
  2 FIL_PAGE_IBUF_BITMAP
  
  195 FIL_PAGE_TYPE_SYS
  
  1 FIL_PAGE_TYPE_TRX_SYS
  
  1 FIL_PAGE_TYPE_FSP_HDR
  
  1 FIL_PAGE_TYPE_XDES
  
  0 FIL_PAGE_TYPE_BLOB
  
  0 FIL_PAGE_TYPE_ZBLOB
  
  0 other
  
  3 max index_id

全部的 20608 中有 19272 个撤销日志页。这占用了表空间的 93%。

第二个检查表空间内容的方式是杰里米·科尔制作的 InnoDB Ruby 工具。它是个检查 InnoDB 的内部结构的更先进的工具。例如我们可以使用 space-summary 参数来得到每个页面及其数据类型的列表。我们可以使用标准的 Unix 工具来统计撤销日志页的数量：

 
 
# innodb_space -f /var/lib/mysql/ibdata1 space-summary | grep UNDO_LOG | wc -l
  
  19272

尽管这种特殊的情况下，innochedcksum 更快更容易使用，但是我推荐你使用杰里米的工具去了解更多的 InnoDB 内部的数据分布及其内部结构。

好，现在我们知道问题所在了。下一个问题：

我该怎么解决问题？

这个问题的答案很简单。如果你还能提交语句，就做吧。如果不能的话，你必须要杀掉线程开始回滚过程。那将停止 ibdata1 的增长，但是很显然，你的软件会出现漏洞，有些人会遇到错误。现在你知道如何去鉴定问题所在，你需要使用你自己的调试工具或普通的查询日志来找出谁或者什么引起的问题。

如果问题发生在清除线程，解决方法通常是升级到新版本，新版中使用一个独立的清除线程替代主线程。更多信息查看该文档

有什么方法回收已使用的空间么？

没有，目前还没有一个容易并且快速的方法。InnoDB 表空间从不收缩...参见10 年之久的漏洞报告，最新更新自詹姆斯·戴（谢谢）：

当你删除一些行，这个页被标为已删除稍后重用，但是这个空间从不会被回收。唯一的方法是使用新的 ibdata1 启动数据库。要做这个你应该需要使用 mysqldump 做一个逻辑全备份，然后停止 MySQL 并删除所有数据库、ib_logfile*、ibdata1* 文件。当你再启动 MySQL 的时候将会创建一个新的共享表空间。然后恢复逻辑备份。

总结

当 ibdata1 文件增长太快，通常是 MySQL 里长时间运行的被遗忘的事务引起的。尝试去解决问题越快越好（提交或者杀死事务），因为不经过痛苦缓慢的 mysqldump 过程，你就不能回收浪费的磁盘空间。

也是非常推荐监控数据库以避免这些问题。我们的 MySQL 监控插件包括一个 Nagios 脚本，如果发现了一个太老的运行事务它可以提醒你。

MySql ibdata1文件太大如何缩小

转自：http://blog.chinaunix.net/uid-24373487-id-4223322.html

MySql innodb如果是共享表空间，ibdata1文件越来越大，达到了30多个G，对一些没用的表进行清空：
truncate table xxx;
然后optimize table xxx; 没有效果
因为对共享表空间不起作用。
mysql ibdata1存放数据，索引等，是MYSQL的最主要的数据。
如果不把数据分开存放的话，这个文件的大小很容易就上了G，甚至几十G。对于某些应用来说，并不是太合适。因此要把此文件缩小。
无法自动收缩，必须数据导出，删除ibdata1，然后数据导入，比较麻烦，因此需要改为每个表单独的文件。
解决方法：数据文件单独存放(共享表空间如何改为每个表独立的表空间文件)。
步骤如下：

1）备份数据库
备份全部数据库，执行命令
#mysqldump -q -uroot -ppassword --add-drop-table --all-databases >/home/backup/all.sql
做完此步后，停止数据库服务。
#service mysqld stop

2）找到my.ini或my.cnf文件
linux下执行
# /usr/libexec/mysqld --verbose --help | grep -A 1 'Default options'
Default options are read from the following files in the given order:
/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf
windows环境下可以：
mysqld --verbose --help > mysqlhelp.txt
notepad mysqlhelp.txt
在里面查找Default options，可以看到查找my.ini的顺序，以找到真实目录

3）修改mysql配置文件
打开my.ini或my.cnf文件
[mysqld]下增加下面配置
innodb_file_per_table=1
验证配置是否生效，可以重启mysql后,执行
#service mysqld restart
#mysql -uroot -ppassword
mysql> show variables like '%per_table%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | ON |
+-----------------------+-------+
1 row in set (0.00 sec)

mysql>

看看innodb_file_per_table变量是否为ON

4）删除原数据文件
删除原来的ibdata1文件及日志文件ib_logfile*，删除/var/lib/mysql目录下的应用数据库文件夹(mysql文件夹不要删)

5）还原数据库
启动数据库服务
从命令行进入MySQL Server
还原全部数据库，执行命令
#service mysqld start
#mysql -uroot -pocs < /home/backup/all.sql

经过以上几步后，可以看到新的ibdata1文件就只有几十M了，数据及索引都变成了针对单个表的小ibd文件了，它们在相应数据库的文件夹下面。

# ll
total 295028
drwx------ 2 mysql mysql 36864 Apr 22 14:16 glpi
drwx------ 2 mysql mysql 36864 Feb 15 13:45 glpi-1
-rw-rw---- 1 mysql mysql 10485760 Apr 22 14:27 ibdata1
-rw-rw----. 1 mysql mysql 270532608 Apr 22 14:14 ibdata1-1
-rw-rw---- 1 mysql mysql 5242880 Apr 22 14:27 ib_logfile0
-rw-rw----. 1 mysql mysql 5242880 Apr 22 14:14 ib_logfile0_bak
-rw-rw---- 1 mysql mysql 5242880 Apr 22 14:28 ib_logfile1
-rw-rw----. 1 mysql mysql 5242880 Apr 21 22:50 ib_logfile1_bak
drwx------ 2 mysql mysql 4096 Apr 22 14:16 mrbs
drwx------ 2 mysql mysql 4096 Apr 14 12:05 mrbs-1
drwx------. 2 mysql mysql 4096 Apr 22 14:16 mysql
srwxrwxrwx 1 mysql mysql 0 Apr 22 14:16 mysql.sock
drwx------ 2 mysql mysql 12288 Apr 22 14:16 ocsweb
drwx------ 2 mysql mysql 12288 Nov 16 2011 ocsweb-1

# ll mrbs
total 808
-rw-rw---- 1 mysql mysql 61 Apr 22 14:16 db.opt
-rw-rw---- 1 mysql mysql 10492 Apr 22 14:16 mrbs_area.frm
-rw-rw---- 1 mysql mysql 98304 Apr 22 14:16 mrbs_area.ibd
-rw-rw---- 1 mysql mysql 9264 Apr 22 14:16 mrbs_entry.frm
-rw-rw---- 1 mysql mysql 131072 Apr 22 14:16 mrbs_entry.ibd
-rw-rw---- 1 mysql mysql 9442 Apr 22 14:16 mrbs_repeat.frm
-rw-rw---- 1 mysql mysql 98304 Apr 22 14:16 mrbs_repeat.ibd
-rw-rw---- 1 mysql mysql 8888 Apr 22 14:16 mrbs_room.frm
-rw-rw---- 1 mysql mysql 114688 Apr 22 14:16 mrbs_room.ibd
-rw-rw---- 1 mysql mysql 8688 Apr 22 14:16 mrbs_users.frm
-rw-rw---- 1 mysql mysql 98304 Apr 22 14:16 mrbs_users.ibd
-rw-rw---- 1 mysql mysql 8658 Apr 22 14:16 mrbs_variables.frm
-rw-rw---- 1 mysql mysql 98304 Apr 22 14:16 mrbs_variables.ibd
-rw-rw---- 1 mysql mysql 8738 Apr 22 14:16 mrbs_zoneinfo.frm
-rw-rw---- 1 mysql mysql 98304 Apr 22 14:16 mrbs_zoneinfo.ibd

# ll mrbs-1
total 88
-rw-rw---- 1 mysql mysql 61 Apr 14 12:05 db.opt
-rw-rw---- 1 mysql mysql 10492 Apr 14 12:05 mrbs_area.frm
-rw-rw---- 1 mysql mysql 9264 Apr 14 12:05 mrbs_entry.frm
-rw-rw---- 1 mysql mysql 9442 Apr 14 12:05 mrbs_repeat.frm
-rw-rw---- 1 mysql mysql 8888 Apr 14 12:05 mrbs_room.frm
-rw-rw---- 1 mysql mysql 8688 Apr 14 12:05 mrbs_users.frm
-rw-rw---- 1 mysql mysql 8658 Apr 14 12:05 mrbs_variables.frm
-rw-rw---- 1 mysql mysql 8738 Apr 14 12:05 mrbs_zoneinfo.frm

秒客网

mysql 里的 ibdata1 文件

ibdata1存了什么？

什么引起 ibdata1 增长迅速？

我怎么检查什么被存储到了 ibdata1 里了？

我该怎么解决问题？

有什么方法回收已使用的空间么？

总结

相关文章