做了mysql主從也有一 段時間了，這兩天檢查磁盤空間情況，發現放數據庫的分區磁盤激增了40多G，一路查看下來，發現配置好主從復制以來到現在的binlog就有40多G，原 來根源出在這裏查看了一下my.cnf，看到binlog的size是1G就做分割，但沒有看到刪除的配置，在mysql裏show了一下 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之間的時間相距是一年, 或者在不同的二進制日誌中, 且位置相距好遠, 就等著失眠吧! 做好備份, 小心操作才是正路啊！
留言列表
