专业网站建设公司兴田德润在哪里,wordpress 上传失败,德山经济开发区建设局网站,典型营销型网站有哪些我们在 Percona 支持栏目经常收到关于 MySQL 的 ibdata1 文件的这个问题。当监控服务器发送一个关于 MySQL 服务器存储的报警时#xff0c;恐慌就开始了 —— 就是说磁盘快要满了。一番调查后你意识到大多数地盘空间被 InnoDB 的共享表空间 ibdata1 使用。而你已经启用了 inno…我们在 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 出现问题通常我们需要执行的第一个命令是:1SHOW ENGINE INNODB STATUS/G这将展示给我们一些很有价值的信息。我们从** TRANSACTION(事务)**部分开始检查然后我们会发现这个1234---TRANSACTION36E,ACTIVE1256288secMySQL thread id42,OS thread handle0x7f8baaccc700,query id7900290localhost rootshow engine innodb statusTrx read view will notsee trx with id36F,sees36F这是一个最常见的原因一个14天前创建的相当老的事务。这个状态是活动的这意味着 InnoDB 已经创建了一个数据的快照所以需要在撤销日志中维护旧页面以保障数据库的一致性视图直到事务开始。如果你的数据库有大量的写入任务那就意味着存储了大量的撤销页。如果你找不到任何长时间运行的事务你也可以监控INNODB STATUS 中的其他的变量“History list length(历史记录列表长度)”展示了一些等待清除操作。这种情况下问题经常发生因为清除线程(或者老版本的主线程)不能像这些记录进来的速度一样快地处理撤销。我怎么检查什么被存储到了 ibdata1 里了很不幸MySQL 不提供查看什么被存储到 ibdata1 共享表空间的信息但是有两个工具将会很有帮助。第一个是马克·卡拉汉制作的一个修改版 innochecksum 它发布在这个漏洞报告里。它相当易于使用12345678910111213141516# ./innochecksum /var/lib/mysql/ibdata10bad checksum13FIL_PAGE_INDEX19272FIL_PAGE_UNDO_LOG230FIL_PAGE_INODE1FIL_PAGE_IBUF_FREE_LIST892FIL_PAGE_TYPE_ALLOCATED2FIL_PAGE_IBUF_BITMAP195FIL_PAGE_TYPE_SYS1FIL_PAGE_TYPE_TRX_SYS1FIL_PAGE_TYPE_FSP_HDR1FIL_PAGE_TYPE_XDES0FIL_PAGE_TYPE_BLOB0FIL_PAGE_TYPE_ZBLOB0other3max index_id全部的 20608 中有 19272 个撤销日志页。这占用了表空间的 93%。第二个检查表空间内容的方式是杰里米·科尔制作的 InnoDB Ruby 工具。它是个检查 InnoDB 的内部结构的更先进的工具。例如我们可以使用 space-summary 参数来得到每个页面及其数据类型的列表。我们可以使用标准的 Unix 工具来统计撤销日志页的数量12# innodb_space -f /var/lib/mysql/ibdata1 space-summary | grep UNDO_LOG | wc -l19272尽管这种特殊的情况下innochedcksum 更快更容易使用但是我推荐你使用杰里米的工具去了解更多的 InnoDB 内部的数据分布及其内部结构。好现在我们知道问题所在了。下一个问题我该怎么解决问题这个问题的答案很简单。如果你还能提交语句就做吧。如果不能的话你必须要杀掉线程开始回滚过程。那将停止 ibdata1 的增长但是很显然你的软件会出现漏洞有些人会遇到错误。现在你知道如何去鉴定问题所在你需要使用你自己的调试工具或普通的查询日志来找出谁或者什 么引起的问题。如果问题发生在清除线程解决方法通常是升级到新版本新版中使用一个独立的清除线程替代主线程。更多信息查看该文档有什么方法回收已使用的空间么没有目前还没有一个容易并且快速的方法。InnoDB 表空间从不收缩...参见10 年之久的漏洞报告最新更新自詹姆斯·戴(谢谢)当你删除一些行这个页被标为已删除稍后重用但是这个空间从不会被回收。唯一的方法是使用新的 ibdata1 启动数据库。要做这个你应该需要使用 mysqldump 做一个逻辑全备份然后停止 MySQL 并删除所有数据库、ib_logfile*、ibdata1* 文件。当你再启动 MySQL 的时候将会创建一个新的共享表空间。然后恢复逻辑备份。总结当 ibdata1 文件增长太快通常是 MySQL 里长时间运行的被遗忘的事务引起的。尝试去解决问题越快越好(提交或者杀死事务)因为不经过痛苦缓慢的 mysqldump 过程你就不能回收浪费的磁盘空间。也是非常推荐监控数据库以避免这些问题。我们的 MySQL 监控插件包括一个 Nagios 脚本如果发现了一个太老的运行事务它可以提醒你。
