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的選項：
<code>mysqlbinlog --raw --read-from-remote-server --stop-never</code>
它會偽裝成mysql從庫，從遠程獲取binlog然后進行轉儲。這對線上主庫容量不夠無法保存較多binlog的場景非常有用。但是，它畢竟不像真正的mysql從庫實例，狀態監控和同步都需要單獨部署。因此個人覺得采用blackhole來備份全量的binlog是更好的選擇。筆者曾經實現過一個自動搭建blackhole從庫的工具，稍加修改，就可以完美搭建出blackhole從庫。一旦同步起來，基本一勞永逸，很少出問題，主從切換的時候跟著切了就行。
提示：
不要小看binlog的備份。當5.6的多線程復制大規模使用后，從庫追趕主庫命令點的耗時將被極大縮短，這樣我們把每天一次的全量備份改為每3天一次、甚至每周一次的全量備份，和持續的binlog增量備份。遇到故障需要恢復數據的時候，重放3、5天的binlog也是極快的。降低備份頻率最直接的好處是，省錢、省事。
blackhole對于備份binlog是極好的。一方面可以長久的備份binlog用于恢復數據庫，另一方面，在其上配置半同步復制，可以有效防止主庫的binlog丟失。
總結
備份方式各有千秋，而對我們來說，面對數千實例，選擇合適的備份工具來實現統一配置、統一規劃，構建智能調度的備份云平臺才是王道。畢竟，多種備份方式共存的運維成本是不容忽視的。
從使用經驗來看，用Xtrabackup全備數據，用blackhole增備binlog，并定期對備份數據的有效性進行驗證，是當下比較好的選擇。