前一陣子工作項目上的事情忙的焦頭爛額，最近要進行部門調整將要去做新的項目。又要學習很多新的知識了，還是很興奮激動的。今天下班回來查看了一下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是安全的，一般來說網絡狀況好的時候，保留最新的那一個足以。