mysqlbinlog工具基於日誌恢復詳細解釋

muxinqing發表於2014-05-17

如果每天都會生成大量的二進位制日誌,這些日誌長時間不清理的話,將會對磁碟空間帶來很大的浪費,所以定期清理日誌是DBA維護mysql的一個重要工作

1)RESET MASTER
在上面檢視日誌存放的資料夾中,二進位制日誌命名的格式是以mysql-bin.*,*代表日誌的序號,序號是遞增的,其中還有mysql-bin.index是日誌的索引檔案,記錄了日誌的最大序號
我們執行RESET MASTER命名刪除全部日誌

mysqlbinlog工具基於日誌恢復詳細解釋

檢視刪除後的日誌

mysqlbinlog工具基於日誌恢復詳細解釋

可以看到,以前的日誌全部被清空,新的日誌從00001開始

2)PURGE MASTER LOGS TO & PURGE MASTER LOGS BEFORE
執行PURGE MASTER LOGS TO 'mysql-bin.******'命令,是將'******'編號之前的所有日誌進行刪除
執行PURGE MASTER LOGS BEFORE 'yyyy-mm-dd hh:mm:ss'命令,是將在'yyyy-mm-dd hh:mm:ss'時間之前的所有日誌進行刪除

3)-EXPIRE_LOGS_DAYS
此引數是設定日誌的過期天數,過期的日誌將會被自動刪除,這有利於減少我們管理日誌的工作量,需要修改my.cnf

mysqlbinlog工具基於日誌恢復詳細解釋
這裡我們設定儲存日誌為3天,3天之後過期的日誌將被自動刪除

恢復
 bin-log是記錄著mysql所有事件的操作,當mysql發生災難性錯誤時,可以透過bin-log做完整恢復,基於時間點的恢復,和基於位置的恢復


完整恢復,假定我們每天凌晨2點都會使用mysqldump備份資料庫,但在第二天早上9點由於資料庫出現了故障,資料無法訪問,需要恢復資料,先使用昨天凌晨備份的檔案進行恢復到凌晨2點的狀態,在使用mysqlbinlog恢復自mysqldump備份以來的binlog
mysql localhost mysql-bin.000001 | mysql -uroot -p
這樣資料庫就可以完全的恢復到崩潰前的完全狀態

基於時間點的恢復
,由於誤操作,比如說刪除了一張表,這時使用上面講的完全恢復是沒有用的,因為日誌裡面還存在誤操作的語句,,我們需要的是恢復到誤操作前的狀態,然後跳過誤操作的語句,再恢復後面操作的語句,假定我們刪除了一張表的誤操作發生在10:00這個時間點,我們可以使用下面的語句用備份和binlog將資料恢復到故障前

mysqlbinlog --stop-date='2010-09-04 9:59:59' /var/log/mysql-bin.000001 | mysql -uroot -p


然後跳過誤操作的時間點,繼續執行後面的binlog

mysqlbinlog --start-date='2010-09-04 10:01:00' /var/log/mysql-bin.000001 | mysql -uroot -p


其中--stop-date='2010-09-04 9:59:59' 和 --start-date='2010-09-04 10:01:00' 其中的時間是你誤操作的時間點,當然了,這個時間點你需要你自己計算的,而且這個時間點還可以涉及到的不只是誤操作,還可以有正確的操作也被跳過去了。

基於位置恢復,由於上面提到的,使用基於時間點的恢復可能出現,在一個時間點裡面可能存在誤操作和其他正確的操作,所以我們需要一種更為精確的恢復方式
使用mysqlbinlog檢視二進位制,可看到

mysqlbinlog工具基於日誌恢復詳細解釋

其中drop tables test1這個誤操作的end_log_pos為8879917,幾下這個id,得出它前後操作的id分別為8879916,8879918
我們將進行位置恢復操作

mysqlbinlog --stop-position='8879916' /var/log/mysql-bin.000001 | mysql -uroot -p

mysqlbinlog --start-position='8879918' /var/log/mysql-bin.000001 | mysql -uroot -p

伺服器生成的二進位制日誌檔案寫成二進位制格式。要想檢查這些文字格式的檔案,應使用mysqlbinlog實用工具。
應這樣呼叫mysqlbinlog
shell> mysqlbinlog [options] log-files例如,要想顯示二進位制日誌binlog.000003的內容,使用下面的命令:
shell> mysqlbinlog binlog.0000003輸出包括在binlog.000003中包含的所有語句,以及其它資訊例如每個語句花費的時間、客戶發出的執行緒ID、發出執行緒時的時間戳等等。
通常情況,可以使用mysqlbinlog直接讀取二進位制日誌檔案並將它們用於本地MySQL伺服器。也可以使用–read-from-remote-server選項從遠端伺服器讀取二進位制日誌。
當讀取遠端二進位制日誌時,可以透過連線引數選項來指示如何連線伺服器,但它們經常被忽略掉,除非你還指定了–read-from-remote-server選項。這些選項是–host、–password、–port、–protocol、–socket和–user。
還可以使用mysqlbinlog來讀取在複製過程中從伺服器所寫的中繼日誌檔案。中繼日誌格式與二進位制日誌檔案相同。

mysqlbinlog支援下面的選項:
·
—help,-?
顯示幫助訊息並退出。
·
—database=db_name,-d db_name
只列出該資料庫的條目(只用本地日誌)。
·
–force-read,-f
使用該選項,如果mysqlbinlog讀它不能識別的二進位制日誌事件,它會列印警告,忽略該事件並繼續。沒有該選項,如果mysqlbinlog讀到此類事件則停止。
·
–hexdump,-H
在註釋中顯示日誌的十六進位制轉儲。該輸出可以幫助複製過程中的除錯。在MySQL 5.1.2中新增了該選項。
·
–host=host_name,-h host_name
獲取給定主機上的MySQL伺服器的二進位制日誌。
·
–local-load=path,-l pat
為指定目錄中的LOAD DATA INFILE預處理本地臨時檔案。
·
–offset=N,-o N
跳過前N個條目。
·
–password[=password],-p[password]
當連線伺服器時使用的密碼。如果使用短選項形式(-p),選項和 密碼之間不能有空格。如果在命令列中–password或-p選項後面沒有 密碼值,則提示輸入一個密碼。
·
–port=port_num,-P port_num
用於連線遠端伺服器的TCP/IP埠號。
·
–position=N,-j N
不贊成使用,應使用–start-position。
·
–protocol={TCP | SOCKET | PIPE | -position

使用的連線協議。
·
–read-from-remote-server,-R
從MySQL伺服器讀二進位制日誌。如果未給出該選項,任何連線引數選項將被忽略。這些選項是–host、–password、–port、–protocol、–socket和–user。
·
–result-file=name, -r name
將輸出指向給定的檔案。
·
–short-form,-s
只顯示日誌中包含的語句,不顯示其它資訊。
·
–socket=path,-S path
用於連線的套接字檔案。
·
–start-datetime=datetime
從二進位制日誌中第1個日期時間等於或晚於datetime參量的事件開始讀取。datetime值相對於執行mysqlbinlog的機器上的本地時區。該值格式應符合DATETIME或TIMESTAMP資料型別。例如:
shell> mysqlbinlog –start-datetime=”2004-12-25 11:25:56″ binlog.000003該選項可以幫助點對點恢復。
·
–stop-datetime=datetime
從二進位制日誌中第1個日期時間等於或晚於datetime參量的事件起停止讀。關於datetime值的描述參見–start-datetime選項。該選項可以幫助及時恢復。
·
–start-position=N
從二進位制日誌中第1個位置等於N參量時的事件開始讀。
·
–stop-position=N
從二進位制日誌中第1個位置等於和大於N參量時的事件起停止讀。
·
–to-last-logs,-t
在MySQL伺服器中請求的二進位制日誌的結尾處不停止,而是繼續列印直到最後一個二進位制日誌的結尾。如果將輸出傳送給同一臺MySQL伺服器,會導致無限迴圈。該選項要求–read-from-remote-server。
·
–disable-logs-bin,-D
禁用二進位制日誌。如果使用–to-last-logs選項將輸出傳送給同一臺MySQL伺服器,可以避免無限迴圈。該選項在崩潰恢復時也很有用,可以避免複製已經記錄的語句。註釋:該選項要求有SUPER許可權。
·
–user=user_name,-u user_name
連線遠端伺服器時使用的MySQL使用者名稱。
·
–version,-V
顯示版本資訊並退出。

 

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

相關文章