關於不完全恢復的一些思考

壹頁書發表於2015-06-07
還是有感於ITPUB上次丟失一天資料的問題.
記得當時是一片冷嘲熱諷
我也很奇怪,一個關於資料庫的論壇,為什麼沒有進行不完全恢復.

直到今天我在集中備份伺服器上測試了一下恢復.
我發現當時itpub的dba可能也有相當的苦衷.
如果這種事情發生在我們公司,如何恢復還確實是需要權衡的一件事情.

我先恢復了一個凌晨3點生產資料庫的備份.
然後通過binlog將資料庫推至早晨9點
mysqlbinlog --start-position=374720715 --stop-datetime='2015-06-07 09:00:00' mysql-bin.004989 mysql-bin.004990> /data/tmp/test.sql
這個test.sql檔案有1.7G
執行這個binlog從09:26至10:06結束,共計花費30分鐘

然後修改了引數innodb_flush_log_at_trx_commit=0
再將9點至10點的binlog匯出
mysqlbinlog --start-datetime='2015-06-07 09:00:00' --stop-datetime='2015-06-07 10:00:00' mysql-bin.004989 mysql-bin.004990> /data/tmp/test2.sql
test2.sql有962M
執行test2.sql,從10:15開始至10:29結束,大致用時15分鐘.

假設下午4點半出現誤操作,需要恢復至4點的資料
僅僅是使用binlog進行不完全恢復的時間,大致就是
135分鐘(30+7*15,從凌晨3點到9點需要30分鐘,假設9點以後每個小時需要15分鐘恢復)
也就是2小時零15分鐘!!
而實際時間應該比這個還要長些.估計3小時以內能恢復就不錯了.中間還不能出現任何差錯

這時候,估計已經裡三層外三層的把dba包的水洩不通了..
每分鐘的停機,都是真金白銀的損失(攜程..)
是損失一些資料先把系統拉起來,還是儘量保一些資料,確實是一個值得權衡的事情.
(不過這種權衡已經不是dba能做的了..都是領導決定的..不過領導肯定會狠狠的給你一個白眼..)

有幾個思考

1.為什麼會有這麼多binlog資料?
在我們單位日誌是記錄在生產庫的,甚至都不是單獨的schema
大量的日誌確實給恢復造成了極大的壓力.
如果我設計系統,一定會將日誌放在單獨的資料庫,最起碼也是單獨的schema

2.不同於mysqldump,不完全恢復調整innodb_flush_log_at_trx_commit引數似乎作用不大.

3.異地恢復之前一定要調整的引數
innodb_buffer_pool_size
max_allowed_packet(要恢復的目標伺服器配置低於源伺服器的配置,可能報錯,導致恢復失敗!!)

4.增加force引數
mysql -uroot -p --force -S mysql.sock < /data/test.sql 

5.備份本質上是防止人為的錯誤,而下午又是高發期.
考慮是否在下午1點,增加一個全備份.

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

相關文章