案例分享-MySQL服務(wù)器/tmp目錄被占滿

描述:

MySQL服務(wù)器在每天的22點/tmp目錄磁盤空間被占滿,持續(xù)10分鐘左右,然后自動恢復(fù)./tmp目錄大小10G,平時可用空間8G左右.MySQL版本 5.5

分析

1. ? ? ? 在問題出現(xiàn)時,進入/tmp目錄,ls –al查看具體文件.

2. ? ? ? 在問題出現(xiàn)時,登錄MySQL,執(zhí)行show processlist查看是否存在異常SQL.

3. ? ? ? 查看MySQL慢查詢?nèi)罩?

4. ? ? ? MySQL配置情況:

a) ? ? ? ? default_storage_engine ? ? ? ? = InnoDB

b) ? ? ? ? transaction_isolation ? ? ? ? ? = READ-COMMITTED

c) ? ? ? ? binlog_format ? ? ? ? ? ? ? ? = mixed

d) ? ? ? ? binlog_cache_size ? ? ? ? ? ? ?= 32K

e) ? ? ? ? max_binlog_cache_size ? ? ? ? = 18446744073709547520

f) ? ? ? ? ?tmpdir ? ? ? ? ? ? ? ? ? ? ? = /tmp

總結(jié)

1. ? ? ? InnoDB存儲引擎,在READ-COMMITTED事務(wù)隔離級別的情況下(默認的級別是REPEATABLE-READ),普通的DELETE操作,在記錄binlog的時候,會采用ROW模式.(暫時還不清楚原因,以后分析).

2. ? ? ? 程序在每天的22點,有一個清理的定時任務(wù).自動刪除R表的數(shù)據(jù),如下:

delete from R where time < xxx;

將某天之前的數(shù)據(jù)清除.但是該表比較大,近50G.

3. ? ? ? MySQL參數(shù)

binlog_cache_size

max_binlog_cache_size

參考http://dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html

4. ? ? ? 每次執(zhí)行定時任務(wù)的時候,因為binlog記錄的是ROW模式,再加上表的數(shù)據(jù)量比較大,binlog緩存一定會超過32K,結(jié)果就會在/tmp目錄下生成臨時文件(參考: When a thread that handles the transaction starts, it allocates a buffer of binlog_cache_size to buffer statements. If a statement is bigger than this, the thread opens a temporary file to store the transaction. The temporary file is deleted when the thread ends),MySQL默認配置,在64位系統(tǒng)情況下,binlog文件大小最大可以達到16EB.但是系統(tǒng)的/tmp目錄是10G,所以事務(wù)執(zhí)行一半,磁盤空間被占滿,事務(wù)回滾.

5. ? ? ? 事后查看R表的數(shù)據(jù)以及binlog記錄,驗證了第4步的推論.

解決

在沒有新數(shù)據(jù)寫入的前提下,把確定保留的數(shù)據(jù)先放到新表里面,然后刪除舊表,再把新表重命名.

create table R_20130220 select * FROM R where ?time >= xxx;

DROP TABLE R;

RENAME TABLE R_20130220 TO R;

隔天觀察nagios和cacti監(jiān)控,故障恢復(fù).

原文：http://2853725.blog.51cto.com/2843725/1394423

總結(jié)

以上是生活随笔為你收集整理的linux下mysql tmp满_MySQL服务器/tmp目录被占满的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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