前一陣子工作項目上的事情忙的焦頭爛額,最近要進行部門調整將要去做新的項目。又要學習很多新的知識了,還是很興奮激動的。今天下班回來查看了一下VPS狀態,發現VPS的空間只剩下了1G多!第一反應是被入侵了,但是看了一下log並沒有發現什麼異常的登錄,加上平時基本都是用私鑰免密碼登錄的VPS,別入侵的可能也不是很大。那我就很疑惑了,因為系統文件占用應該也就3G多,我平時並沒有在VPS放過什麼大文件,不應該一下子少那麼多空間。於是開始一番du查找終於找到了罪魁禍首!原來是mysql的log文件導致的。
裝mysql並運行一段時間後,在mysql目錄下出現一堆類似mysql-bin.000***,從mysql-bin.000001開始一直排列下來,而且占用了大量硬盤空間,高達十幾個G.。原來mysql-bin.000001、mysql-bin.000002等文件是數據庫的操作日志,例如UPDATE一個表,或者DELETE一些數據,即使該語句沒有匹配的數據,這個命令也會存儲到日志文件中,還包括每個語句執行的時間,也會記錄進去的。 這些形如mysql-bin.00001的文件主要是用來做什麼的呢? 1、數據恢復
如果你的數據庫出問題了,而你之前有過備份,那麼可以看日志文件,找出是哪個命令導致你的數據庫出問題了,想辦法挽回損失。
2、主從服務器之間同步數據
主服務器上所有的操作都在記錄日志中,從服務器可以根據該日志來進行,以確保兩個同步。
3、清除辦法
運行 /usr/local/mysql/bin/mysql -u root -p 登錄執行:
reset master;
如果你只有一個mysql服務器,在/etc/ 下面找到my.cnf文件vim /etc/my.cnf把裡面的
#log-bin=mysql-bin
#binlog_format=mixed
這兩行注釋掉,然後將mysql下的var目錄中的這些日志文件全部刪除,重啟mysql服務即可。
但是如果你設置了主從服務器,那麼就需要做以下操作了。
A:在每個從屬服務器上,使用SHOW SLAVE STATUS來檢查它正在讀取哪個日志。
B:使用SHOW MASTER LOGS獲得主服務器上的一系列日志。
C:在所有的從屬服務器中判定最早的日志,這個是目標日志,如果所有的從屬服務器是更新的,就是清單上的最後一個日志。
D:清理所有的日志,但是不包括目標日志,因為從服務器還要跟它同步。 簡單地說,這些MySQL目錄下的形如mysql-bin.000***的文件時MySQL的事務日志。 刪除復制服務器已經拿走的binlog是安全的,一般來說網絡狀況好的時候,保留最新的那一個足以。
注意:刪除mysql-bin日志(mysql-bin.00001)導致mysql無法啟動,這個肯定是沒有修改配置文件了這會有問題的。
編輯my.cnf(一般在etc目錄下)
將log-bin=mysql-bin 注釋掉就OK。(前面加#號)
如果還不行請把binlog_format=mixed這行也注釋掉!
啟動mysql:/etc/init.d/mysql start
再解除剛才的注釋,重新啟動mysql即可:/etc/init.d/mysql restart