本文從binlog恢復數據及Mysqlbinlog文件刪除是作者的工作經驗的總結，希望對各位數據庫管理員有幫助，獻給大家！
做了mysql主從也有一段時間了，這兩天檢查磁盤空間情況，發現放數據庫的分區磁盤激增了40多G，一路查看下來，發現配置好主從復制以來到現在的binlog就有40多G，原來根源出在這裡，查看了一下my.cnf，看到binlog的size是1G就做分割，但沒有看到刪除的配置，在MySQL裡查看了一下variables
MySQL>show variables like '%log%';
查到了
| expire_logs_days | 0 |
這個默認是0，也就是logs不過期，這個是一個global的參數，所以需要執行
set global expire_logs_days=8;
這樣8天前的log就會被刪除了，如果有回復的需要，請做好備份工作，但這樣設置還不行，下次重啟MySQL了，配置又恢復默認了，所以需在my.cnf中設置
expire_logs_days = 8
這樣重啟也不怕了
想要恢愎數據庫以前的資料,執行MySQL>show binlog events;
由於數據量很多，查看起來很麻煩，光打開個文件就要閃半天，所以應該適當刪除部分可不用的日志。
並且如果使用的時間足夠長的話，會把我的硬盤空間都給吃掉
1、登錄系統，/usr/bin/MySQL
使用MySQL查看日志
MySQL>show binary logs;
+—————-+———–+
| Log_name | File_size |
+—————-+———–+
| ablelee.000001 | 150462942 |
| ablelee.000002 | 120332942 |
| ablelee.000003 | 141462942 |
+—————-+———–+
2、刪除bin-log(刪除ablelee.000003之前的而沒有包含ablelee.000003)
MySQL> purge binary logs to ′ablelee.000003′;
Query OK, 0 rows affected (0.16 sec)
3、查詢結果(現在只有一條記錄了)
MySQL> show binlog events\G
*************************** 1. row ***************************
Log_name: ablelee.000003
Pos: 4
Event_type: Format_desc
Server_id: 1
End_log_pos: 106
Info: Server ver: 5.1.26-rc-log, Binlog ver: 4
1 row in set (0.01 sec)
(ablelee.000001和ablelee.000002已被刪除)
MySQL> show binary logs;
+—————-+———–+
| Log_name | File_size |
+—————-+———–+
| ablelee.000003 | 106 |
+—————-+———–+
1 row in set (0.00 sec)
(刪除的其它格式運用!)
PURGE {MASTER | BINARY} LOGS TO ‘log_name’
PURGE {MASTER | BINARY} LOGS BEFORE ‘date’
用於刪除列於在指定的日志或日期之前的日志索引中的所有二進制日志。這些日志也會從記錄在日志索引文件
中的清單中被刪除，這樣被給定的日志成為第一個。
例如：
PURGE MASTER LOGS TO ‘MySQL-bin.010′;
PURGE MASTER LOGS BEFORE ‘2008-06-22 13:00:00′;
清除3天前的 binlog
PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);
BEFORE變量的date自變量可以為’YYYY-MM-DD hh:mm:ss’格式。MASTER和BINARY是同義詞。
如果您有一個活性的從屬服務器，該服務器當前正在讀取您正在試圖刪除的日志之一，則本語句不會起作用，
而是會失敗，並伴隨一個錯誤。不過，如果從屬服務器是休止的，並且您碰巧清理了其想要讀取的日志之一，則從
屬服務器啟動後不能復制。當從屬服務器正在復制時，本語句可以安全運行。您不需要停止它們。
要清理日志，需按照以下步驟：
1. 在每個從屬服務器上，使用SHOW SLAVE STATUS來檢查它正在讀取哪個日志。
2. 使用SHOW MASTER LOGS獲得主服務器上的一系列日志。
3. 在所有的從屬服務器中判定最早的日志。這個是目標日志。如果所有的從屬服務器是更新的，這是清單上的
最後一個日志。
4. 制作您將要刪除的所有日志的備份(這個步驟是自選的，但是建議采用)。
5. 清理所有的日志，但是不包括目標日志。
下面講一下怎麼從二進制文件恢復數據, 假如不小心執行了drop table xxx_db, 假如你保留了完整的二進制日志的話, 先不要冒汗, 這是可以恢復的.
先看看日志
#MySQLbinlog /diskb/bin-logs/xxx_db-bin.000001
找到執行create table xxx_db之後和drop table xxx_db之前的position, 假如是20, 1000
#mysqlbinlog --start-position="4" --stop-position="1000" /diskb/bin-logs/xxx_db-bin.000001 | MySQL -u root
伴隨著一大堆的ERROR 1062 (23000) at line 12355: Duplicate entry '139' for key 1, 數據庫就這樣恢復了, 不過--start-position="20"是不行的, 必須從--start-position="4"開始, 為什麼要強制從4開始, 這個問題我也暫時沒有搞清楚.
還有一種辦法是根據日期來恢復
#mysqlbinlog --start-datetime="2009-09-14 0:20:00" --stop-datetim="2009-09-15 01:25:00" /diskb/bin-logs/xxx_db-bin.000001 | MySQL -u root
如果create table xxx_db和drop table xxx_db之間的時間相距是一年, 或者在不同的二進制日志中, 且位置相距好遠, 就等著失眠吧! 做好備份, 小心操作才是正路啊！
