我們在?Percona 支持欄目經(jīng)常收到關(guān)于 MySQL 的 ibdata1 文件的這個(gè)問題。當(dāng)監(jiān)控服務(wù)器發(fā)送一個(gè)關(guān)于 MySQL 服務(wù)器存儲的報(bào)警時(shí)，恐慌就開始了 —— 就是說磁盤快要滿了。一番調(diào)查后你意識到大多數(shù)地盤空間被 InnoDB 的共享表空間 ibdata1 使用。而你已經(jīng)啟用了?innodb_file_per_table，所以問題是：

ibdata1存了什么？

當(dāng)你啟用了?innodb_file_per_table，表被存儲在他們自己的表空間里，但是共享表空間仍然在存儲其它的 InnoDB 內(nèi)部數(shù)據(jù)：

數(shù)據(jù)字典，也就是 InnoDB 表的元數(shù)據(jù)

變更緩沖區(qū)

雙寫緩沖區(qū)

撤銷日志

其中的一些在?Percona 服務(wù)器上可以被配置來避免增長過大的。例如你可以通過?innodb_ibuf_max_size?設(shè)置最大變更緩沖區(qū)，或設(shè)置?innodb_doublewrite_file?來將雙寫緩沖區(qū)存儲到一個(gè)分離的文件。

MySQL 5.6 版中你也可以創(chuàng)建外部的撤銷表空間，所以它們可以放到自己的文件來替代存儲到 ibdata1。可以看看這個(gè)文檔。

什么引起 ibdata1 增長迅速？

當(dāng) MySQL 出現(xiàn)問題通常我們需要執(zhí)行的第一個(gè)命令是:

1

SHOW ENGINE INNODB STATUS/G

這將展示給我們一些很有價(jià)值的信息。我們從** TRANSACTION(事務(wù))**部分開始檢查，然后我們會發(fā)現(xiàn)這個(gè)

1

2

3

4

---TRANSACTION36E,ACTIVE1256288sec

MySQL thread id42,OS thread handle0x7f8baaccc700,query id7900290localhost root

show engine innodb status

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

這是一個(gè)最常見的原因，一個(gè)14天前創(chuàng)建的相當(dāng)老的事務(wù)。這個(gè)狀態(tài)是活動的，這意味著 InnoDB 已經(jīng)創(chuàng)建了一個(gè)數(shù)據(jù)的快照，所以需要在撤銷日志中維護(hù)舊頁面，以保障數(shù)據(jù)庫的一致性視圖，直到事務(wù)開始。如果你的數(shù)據(jù)庫有大量的寫入任務(wù)，那就意味著存儲了大量的撤銷頁。

如果你找不到任何長時(shí)間運(yùn)行的事務(wù)，你也可以監(jiān)控INNODB STATUS 中的其他的變量，“History list length(歷史記錄列表長度)”展示了一些等待清除操作。這種情況下問題經(jīng)常發(fā)生，因?yàn)榍宄€程(或者老版本的主線程)不能像這些記錄進(jìn)來的速度一樣快地處理撤銷。

我怎么檢查什么被存儲到了 ibdata1 里了？

很不幸，MySQL 不提供查看什么被存儲到 ibdata1 共享表空間的信息，但是有兩個(gè)工具將會很有幫助。第一個(gè)是馬克·卡拉漢制作的一個(gè)修改版 innochecksum ，它發(fā)布在這個(gè)漏洞報(bào)告里。

它相當(dāng)易于使用：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

# ./innochecksum /var/lib/mysql/ibdata1

0bad checksum

13FIL_PAGE_INDEX

19272FIL_PAGE_UNDO_LOG

230FIL_PAGE_INODE

1FIL_PAGE_IBUF_FREE_LIST

892FIL_PAGE_TYPE_ALLOCATED

2FIL_PAGE_IBUF_BITMAP

195FIL_PAGE_TYPE_SYS

1FIL_PAGE_TYPE_TRX_SYS

1FIL_PAGE_TYPE_FSP_HDR

1FIL_PAGE_TYPE_XDES

0FIL_PAGE_TYPE_BLOB

0FIL_PAGE_TYPE_ZBLOB

0other

3max index_id

全部的 20608 中有 19272 個(gè)撤銷日志頁。這占用了表空間的 93%。

第二個(gè)檢查表空間內(nèi)容的方式是杰里米·科爾制作的?InnoDB Ruby 工具。它是個(gè)檢查 InnoDB 的內(nèi)部結(jié)構(gòu)的更先進(jìn)的工具。例如我們可以使用 space-summary 參數(shù)來得到每個(gè)頁面及其數(shù)據(jù)類型的列表。我們可以使用標(biāo)準(zhǔn)的 Unix 工具來統(tǒng)計(jì)撤銷日志頁的數(shù)量：

1

2

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

19272

盡管這種特殊的情況下，innochedcksum 更快更容易使用，但是我推薦你使用杰里米的工具去了解更多的 InnoDB 內(nèi)部的數(shù)據(jù)分布及其內(nèi)部結(jié)構(gòu)。

好，現(xiàn)在我們知道問題所在了。下一個(gè)問題：

我該怎么解決問題？

這個(gè)問題的答案很簡單。如果你還能提交語句，就做吧。如果不能的話，你必須要?dú)⒌艟€程開始回滾過程。那將停止 ibdata1 的增長，但是很顯然，你的軟件會出現(xiàn)漏洞，有些人會遇到錯(cuò)誤。現(xiàn)在你知道如何去鑒定問題所在，你需要使用你自己的調(diào)試工具或普通的查詢?nèi)罩緛碚页稣l或者什 么引起的問題。

如果問題發(fā)生在清除線程，解決方法通常是升級到新版本，新版中使用一個(gè)獨(dú)立的清除線程替代主線程。更多信息查看該文檔

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

沒有，目前還沒有一個(gè)容易并且快速的方法。InnoDB 表空間從不收縮...參見10 年之久的漏洞報(bào)告，最新更新自詹姆斯·戴(謝謝)：

當(dāng)你刪除一些行，這個(gè)頁被標(biāo)為已刪除稍后重用，但是這個(gè)空間從不會被回收。唯一的方法是使用新的 ibdata1 啟動數(shù)據(jù)庫。要做這個(gè)你應(yīng)該需要使用 mysqldump 做一個(gè)邏輯全備份，然后停止 MySQL 并刪除所有數(shù)據(jù)庫、ib_logfile*、ibdata1* 文件。當(dāng)你再啟動 MySQL 的時(shí)候?qū)?chuàng)建一個(gè)新的共享表空間。然后恢復(fù)邏輯備份。

總結(jié)

當(dāng) ibdata1 文件增長太快，通常是 MySQL 里長時(shí)間運(yùn)行的被遺忘的事務(wù)引起的。嘗試去解決問題越快越好(提交或者殺死事務(wù))，因?yàn)椴唤?jīng)過痛苦緩慢的 mysqldump 過程，你就不能回收浪費(fèi)的磁盤空間。

也是非常推薦監(jiān)控?cái)?shù)據(jù)庫以避免這些問題。我們的?MySQL 監(jiān)控插件包括一個(gè)?Nagios?腳本，如果發(fā)現(xiàn)了一個(gè)太老的運(yùn)行事務(wù)它可以提醒你。

總結(jié)

以上是生活随笔為你收集整理的mysql 5.6 ibdata1_mysql 里的 ibdata1 文件不断的增长？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。