MySQL二進位制日誌刪除與恢復

luashin發表於2016-03-13

# vim /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
# old_passwords=1
table_cache = 300
default-character-set = utf8
log = /var/lib/mysqllog/mysql.log
log-bin = /var/lib/mysqllog/log-bin
log-slow-queries = /var/lib/mysqllog/slowquery.log
long_query_time=2

[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
其中黑體的內容為增加的,斜體的log-error=/var/log/mysqld.log原有的
mysql有以下幾種日誌: 
錯誤日誌:  -log-err  
查詢日誌:  -log 
慢查詢日誌: -log-slow-queries 
更新日誌:   -log-update    這個版本已經不用了,update的操作也記入查詢日誌中。設定上後錯誤日誌中會有一條錯誤資訊,不過不影響使用
二進位制日誌: -log-bin 


附錄:

//顯示所有本機上的二進位制日誌
mysql> SHOW MASTER LOGS;

//刪除所有本機上的二進位制日誌
mysql> RESET MASTER;

//刪除所有建立時間在binary-log.xxx之前的二進位制日誌
mysql> PURGE MASTER LOGS TO 'binary-log.xxx';

//只保留最近6天的日誌,之前的都刪掉
find /var/intra -type f -mtime +6 -name "*.log" -exec rm -f {} \;

//用鍵盤左上角(也就是Esc下面)那個鍵包圍起來,說明是命令。-1d是昨天,以此類推-1m是上個月等等
day=`/bin/date -v -1d +%Y%m%d`;

//給檔案改名
mv xxx.log xxx-${day}.log;

//這裡還要加上資料庫的使用者名稱密碼,作用是更新日誌(包括二進位制日誌和查詢日誌等等)
mysqladmin flush-logs

 

開啟MySQL的慢查詢日誌記錄

   MySQL慢查詢日誌對於跟蹤有問題的查詢非常有用,可以分析出當前程式裡有很耗費資源的sql語句,那如何開啟mysql的慢查詢日誌記錄呢?
其實開啟mysql的慢查詢日誌很簡單,只需要在mysql的配置檔案裡(windows系統是my.ini,linux系統是my.cnf)的[mysqld]下面加上如下程式碼:

log-slow-queries=/var/lib/mysql/slowquery.log
long_query_time=2
注:
log-slow-queries設定把日誌寫在那裡,為空的時候,系統會給慢查詢日誌賦予主機名,並被附加slow.log。
/var/lib/mysql/slowquery.log為日誌存放的檔案的位置,一般這個目錄要有mysql的執行帳號的可寫許可權,一般都將這個目錄設定為 mysql的資料存放目錄

long_query_time=2中的2表示查詢超過兩秒才記錄.

如果設定了引數log-long-format,那麼所有沒有使用索引的查詢也將被記錄。在檔案my.cnf或my.ini中加入下面這一行可以記錄這些查詢

這是一個有用的日誌。它對於效能的影響不大(假設所有查詢都很快),並且強調了那些最需要注意的查詢(丟失了索引或索引沒有得到最佳應用)

# Time: 070927  8:08:52

# User@Host: root[root] @  [192.168.0.20]

# Query_time: 372  Lock_time: 136  Rows_sent: 152  Rows_examined: 263630
select id, name from manager where id in (66,10135);
這是慢查詢日誌中的一條,用了372秒,鎖了136秒,返回152行,一共查了263630行

   如果日誌內容很多,用眼睛一條一條去看會累死,mysql自帶了分析的工具,使用方法如下:
命令列下,進入mysql/bin目錄,輸入mysqldumpslow –help或--help可以看到這個工具的引數


MySQL的log-bin的日誌功能
   安裝mysql,執行一段時間後,在mysql目錄下出現一堆類似mysql-bin.000***,從mysql-bin.000001開始一直排列下來,而且佔用了大量硬碟空間,高達幾十個G。對於這些超大空間佔用量的檔案應該怎麼辦呢?

那麼mysql資料庫資料夾中的mysql-bin.00001是什麼檔案?
mysql-bin.000001、mysql- bin.000002等檔案是資料庫的操作日誌,例如UPDATE一個表,或者DELETE一些資料,即使該語句沒有匹配的資料,這個命令也會儲存到日誌檔案中,還包括每個語句執行的時間,也會記錄進去。

這些形如mysql-bin.00001的檔案主要是用來做什麼的呢?
1:資料恢復
如果你的資料庫出問題了,而你之前有過備份,那麼可以看日誌檔案,找出是哪個命令導致你的資料庫出問題了,想辦法挽回損失。

2:主從伺服器之間同步資料
主伺服器上所有的操作都在記錄日誌中,從伺服器可以根據該日誌來進行,以確保兩個同步。

如果不想要這些檔案應該怎麼做呢?
1:只有一個mysql伺服器,那麼可以簡單的註釋掉這個選項就行了。
vim /etc/my.cnf把裡面的log-bin這一行註釋掉,重啟mysql服務即可。

2:如果你的環境是主從伺服器,那麼就需要做以下操作了。
A:在每個從屬伺服器上,使用SHOW SLAVE STATUS來檢查它正在讀取哪個日誌。
B:使用SHOW MASTER LOGS獲得主伺服器上的一系列日誌。
C:在所有的從屬伺服器中判定最早的日誌,這個是目標日誌,如果所有的從屬伺服器是更新的,就是清單上的最後一個日誌。
D:清理所有的日誌,但是不包括目標日誌,因為從伺服器還要與它同步。


簡單地說,這些MySQL目錄下的形如mysql-bin.000***的檔案時MySQL的事務日誌。

刪除複製伺服器已經拿走的binlog是安全的,一般來說網路狀況好的時候,保留最新的那一個足以。

mysql二進位制日誌維護

先登陸上去, 看看這臺機器有沒有做replication, 如果有在做的話, 清除bin-log的時候要小心了, 要確保要刪除的bin-log都已經送到slave了.

mysql> show processlist;
+----------+------+-----------+------+---------+------+-------+------------------+
| Id       | User | Host      | db   | Command | Time | State | Info             |
+----------+------+-----------+------+---------+------+-------+------------------+
| 55467761 | root | localhost | NULL | Query   | 0    | NULL  | show processlist |
+----------+------+-----------+------+---------+------+-------+------------------+
沒有binlog dump的執行緒, 說明這臺機器沒有在做replication, 直接用以下命令清除所有的bin-log, 可以刪除列於索引檔案中的所有二進位制日誌,把二進位制日誌索引檔案重新設定為空,並建立一個新的二進位制日誌檔案。

mysql> reset master;
mysql> show master status;
+----------+----------+--------------+------------------+
| File     | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+----------+----------+--------------+------------------+
|xxx.000001| 180      |              |                  |
+----------+----------+--------------+------------------+
假設我只想刪除xxx.000018以前的bin-log, 可以用以下的命令.

mysql> purge master logs to 'xxx.000018'
有條件的機器最好保留一份bin-log在另外一 個磁碟, 就算資料庫掛了, 我們也可以根據二進位制日誌來恢復, 怎麼保留二進位制日誌呢? 編輯你的my.cnf, 指定如下配置log-bin=/diskb/bin-logs/xxx_db-bin, 重新啟動資料庫的時候, 你就會發現/diskb/bin-logs哪裡多了兩個檔案xxx_db-bin.000001, xxx_db-bin.index, 一個是二進位制日誌檔案, 它將更改資料的所有查詢記入該檔案, 另外一個是二進位制日誌檔名的索引檔案.

下面講一下怎麼從二進位制檔案恢復資料, 假如不小心執行了drop table xxx_db, 假如你保留了完整的二進位制日誌的話, 先不要冒汗, 這是可以恢復的.

先看看日誌

mysql> mysqlbinlog /diskb/bin-logs/xxx_db-bin.000001
找到執行create table xxx_db之後和drop table xxx_db之前的position, 假如是20, 1000.

mysql> 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開始, 這個問題我也暫時沒有搞清楚.

還有一種辦法是根據日期來恢復

mysql> 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之間的時間相距是一年, 或者在不同的二進位制日誌中, 且位置相距好遠, 就等著失眠吧! 做好備份, 小心操作才是正路啊..


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/9034054/viewspace-2056444/,如需轉載,請註明出處,否則將追究法律責任。

相關文章