爲MySQL選擇合適的備份方式

數據庫的備份是極其重要的事情。若是沒有備份，遇到下列狀況就會抓狂：

UPDATE or DELETE whitout where…

table was DROPPed accidentally…

INNODB was corrupt…

entire datacenter loses power…

從數據安全的角度來講，服務器磁盤都會作raid，MySQL自己也有主從、drbd等容災機制，但它們都沒法徹底取代備份。容災和高可用能幫咱們 有效的應對物理的、硬件的、機械的故障，而對咱們犯下的邏輯錯誤卻無能爲力。每一種邏輯錯誤發生的機率都極低，可是當多種可能性疊加的時候，小几率事件就 放大成很大的安全隱患，這時候備份的必要性就凸顯了。那麼在衆多的MySQL備份方式中，哪種纔是適合咱們的呢？

常見的備份方式

MySQL自己爲咱們提供了mysqldump、mysqlbinlog遠程備份工具，percona也爲咱們提供了強大的Xtrabackup， 加上開源的mydumper，還有基於主從同步的延遲備份、從庫冷備等方式，以及基於文件系統快照的備份，其實選擇已經多到眼花繚亂。而備份自己是爲了恢 復，因此可以讓咱們在出現故障後迅速、準確恢復的備份方式，就是最適合咱們的，固然，同時可以省錢、省事，那就很是完美。下面就我理解的幾種備份工具進行 一些比較，探討下它們各自的適用場景。

1. mysqldump & mydumper

mysqldump是最簡單的邏輯備份方式。在備份myisam表的時候，若是要獲得一致的數據，就須要鎖表，簡單而粗暴。而在備份innodb表 的時候，加上–master-data=1 –single-transaction 選項，在事務開始時刻，記錄下binlog pos點，而後利用mvcc來獲取一致的數據，因爲是一個長事務，在寫入和更新量很大的數據庫上，將產生很是多的undo，顯著影響性能，因此要慎用。

優勢：簡單，可針對單表備份，在全量導出表結構的時候尤爲有用。

缺點：簡單粗暴，單線程，備份慢並且恢復慢，跨IDC有可能遇到時區問題。

mydumper是mysqldump的增強版。相比mysqldump：

內置支持壓縮，能夠節省2-4倍的存儲空間。

支持並行備份和恢復，所以速度比mysqldump快不少，可是因爲是邏輯備份，仍不是很快。

2. 基於文件系統的快照

基於文件系統的快照，是物理備份的一種。在備份前須要進行一些複雜的設置，在備份開始時刻得到快照並記錄下binlog pos點，而後採用相似copy-on-write的方式，把快照進行轉儲。轉儲快照自己會消耗必定的IO資源，並且在寫入壓力較大的實例上，保存被更改 數據塊的前印象也會消耗IO，最終表現爲總體性能的降低。並且服務器還要爲copy-on-write快照預留較多的磁盤空間，這自己對資源也是一種浪 費。所以這種備份方式咱們使用的很少。

3. Xtrabackup

這或許是最爲普遍的備份方式。percona之因此家喻戶曉，Xtrabackup應該功不可沒。它其實是物理備份+邏輯備份的組合。在備份 innodb表的時候，它拷貝ibd文件，並一刻不停的監視redo log的變化，append到本身的事務日誌文件。在拷貝ibd文件過程當中，ibd文件自己可能被寫」花」，這都不是問題，由於在拷貝完成後的第一個 prepare階段，Xtrabackup採用相似於innodb崩潰恢復的方法，把數據文件恢復到與日誌文件一致的狀態，並把未提交的事務回滾。若是同 時須要備份myisam表以及innodb表結構等文件，那麼就須要用flush tables with lock來得到全局鎖，開始拷貝這些再也不變化的文件，同時得到binlog位置，拷貝結束後釋放鎖，也中止對redo log的監視。

它的工做原理以下：

因爲mysql中不可避免的含有myisam表，同時innobackup並不備份表結構等文件，所以想要完整的備份mysql實例，就少不了要執行 flush tables with read lock，而這個語句會被任何查詢(包括select)阻塞，在阻塞過程當中，它又反過來阻塞任何查詢(包括select)。若是碰巧備份實例上有長查詢先 於flush tables with read lock執行，數據庫就會hang住。而當flush tables with read lock得到全局鎖後，雖然查詢能夠執行，可是仍會阻塞更新，因此，咱們但願flush tables with read lock從發起到結束，持續的時間越短越好。

爲了解決這個問題，有兩種比較有效的方法：

1. 儘可能不用myisam表。

2. Xtrabackup增長了–rsync選項，經過兩次rsync來減小持有全局鎖的時間。

優化後的備份過程以下：

優勢：在線熱備，全備+增備+流備，支持限速，支持壓縮，支持加密。

缺點：須要獲取全局鎖，若是遇到長查詢，等待時間將不可控，所以要作好監控，必要時殺死長查詢或自殺；遇到超大的實例，備份過程較長，redo log太大會影響恢復速度，這種狀況下最好採用延遲備份。

4. mysqlbinlog 5.6

上述全部的備份方式，都只能把數據庫恢復到備份的某個時間點：mysqldump和mydumper，以及snapshot是備份開始的時間 點；Xtrabackup是備份結束的時間點。要想實現point in time的恢復，還必須備份binlog。同時binlog也是實現增備的寶貴資源。

幸運的是，mysql 5.6爲咱們提供了遠程備份binlog的選項：

mysqlbinlog --raw --read-from-remote-server --stop-never

它會假裝成mysql從庫，從遠程獲取binlog而後進行轉儲。這對線上主庫容量不夠沒法保存較多binlog的場景很是有用。可是，它畢竟不像真正的 mysql從庫實例，狀態監控和同步都須要單獨部署。所以我的以爲採用blackhole來備份全量的binlog是更好的選擇。筆者曾經實現過一個自動搭建blackhole從庫的工具，稍加修改，就能夠完美搭建出blackhole從庫。一旦同步起來，基本一勞永逸，不多出問題，主從切換的時候跟着切了就行。

提示：

不要小看binlog的備份。當5.6的多線程複製大規模使用後，從庫追趕主庫命令點的耗時將被極大縮短，這樣咱們把天天一次的全量備份改成每3 天一次、甚至每週一次的全量備份，和持續的binlog增量備份。遇到故障須要恢復數據的時候，重放三、5天的binlog也是極快的。下降備份頻率最直 接的好處是，省錢、省事。

blackhole對於備份binlog是極好的。一方面能夠長久的備份binlog用於恢復數據庫，另外一方面，在其上配置半同步複製，能夠有效防止主庫的binlog丟失。

總結

備份方式各有千秋，而對咱們來講，面對數千實例，選擇合適的備份工具來實現統一配置、統一規劃，構建智能調度的備份雲平臺纔是王道。畢竟，多種備份方式共存的運維成本是不容忽視的。

從使用經驗來看，用Xtrabackup全備數據，用blackhole增備binlog，並按期對備份數據的有效性進行驗證，是當下比較好的選擇。