備份是數據安全的最後一道防線，對於任何數據丟失的場景，備份雖然不一定能恢復百分之百的數據(取決於備份周期)，但至少能將損失降到最低。衡量備份恢復有兩個重要的指標：恢復點目標(RPO)和恢復時間目標(RTO)，前者重點關注能恢復到什麼程度，而後者則重點關注恢復需要多長時間。這篇文章主要討論MySQL的備份方案，重點介紹幾種備份方式的原理，包括文件系統快照(LVM)，邏輯備份工具Mysqldump，Mydumper，以及物理備份工具Xtrabackup，同時會詳細講解幾種方案的優缺點，以及可能遇到的問題。
冷備份
最簡單的備份方式就是，關閉MySQL服務器，然後將data目錄下面的所有文件進行拷貝保存，需要恢復時，則將目錄拷貝到需要恢復的機器即可。這種方式確實方便，但是在生產環境中基本沒什麼作用。因為所有的機器都是要提供服務的，即使是Slave有時候也需要提供只讀服務，所以關閉MySQL停服備份是不現實的。與冷備份相對應的一個概念是熱備份，所謂熱備份是在不影響MySQL對外服務的情況下，進行備份，熱備份是這篇文章討論的重點。
快照備份
首先要介紹的熱備份是快照備份，快照備份是指通過文件系統支持的快照功能對數據庫進行備份。備份的原理是將所有的數據庫文件放在同一分區中，然後對該分區執行快照工作，對於Linux而言，需要通過LVM(Logical Volumn Manager)來實現。LVM使用寫時復制(copy-on-write)技術來創建快照，例如，對整個卷的某個瞬間的邏輯副本，類似於數據庫中的innodb存儲引擎的MVCC，只不過LVM的快照在文件系統層面，而MVCC在數據庫層面，而且僅支持innodb存儲引擎。LVM有一個快照預留區域，如果原始卷數據有變化時，LVM保證在任何變更寫入之前，會復制受影響塊到快照預留區域。簡單來說，快照區域內保留了快照點開始時的一致的所有old數據。對於更新很少的數據庫，快照也會非常小。對於MySQL而言，為了使用快照備份，需要將數據文件，日志文件都放在一個邏輯卷中，然後對該卷快照備份即可。由於快照備份，只能本地，因此，如果本地的磁盤損壞，則快照也就損壞了。快照備份更偏向於對誤操作防范，可以將數據庫迅速恢復到快照產生的時間點，然後結合二進制日志可以恢復到指定的時間點。基本原理如下圖：
邏輯備份
冷備份和快照備份由於其弊端在生產環境中很少使用，使用更多是MySQL自帶的邏輯備份和物理備份工具，這節主要講邏輯備份，MySQL官方提供了Mysqldump邏輯備份工具，雖然已經足夠好，但存在單線程備份慢的問題。在社區提供了更優秀的邏輯備份工具mydumper，它的優勢主要體現在多線程備份，備份速度更快。
Mysqldump
Mysqldump用於備份，不得不提兩個關鍵的參數：
--single-transaction：在開始備份前，執行start transaction命令，以此來獲取一致性備份，該參數僅對innodb存儲引擎有效。
--master-data=2：主要用於記錄一致性備份的位點。
理解Mysqldump工作原理，一定要將事務表(innodb)和非事務表(比如myisam)區別對待，因為備份的流程與此息息相關。而且，到目前為止，我們也無法規避myisam表，即使我們的所有業務表都是innodb，因為mysql庫中系統表仍然采用的myisam表。備份的基本流程如下：
1.調用FTWRL(flush tables with read lock)，全局禁止讀寫
2.開啟快照讀，獲取此時的快照(僅對innodb表起作用)
3.備份非innodb表數據(*.frm,*.myi,*.myd等)
4.非innodb表備份完畢後，釋放FTWRL鎖
5.逐一備份innodb表數據
6.備份完成。
整個過程，可以參考我同事的一張圖，但他的這張圖只考慮innodb表的備份情況，實際上在unlock tables執行完畢之前，非innodb表已經備份完畢，後面的t1,t2和t3實質都是innodb表，而且5.6的mysqldump利用保存點機制，每備份完一個表就將一個表上的MDL鎖釋放，避免對一張表鎖更長的時間。這裡可以參考我之前的blog：FLUSH TABLE WITH READ LOCK
大家可能有一個疑問，為啥備份innodb表之前，就已經將鎖釋放掉了，這實際上是利用了innodb引擎的MVCC機制，開啟快照讀後，就能獲取那個時間的一致的數據，無論需要備份多長時間，直到整個事務結束(commit)為止。
Mydumper
Mydumper原理與Mysqldump原理類似，最大的區別是引入了多線程備份，每個備份線程備份一部分表，當然並發粒度可以到行級，達到多線程備份的目的。這裡要解決最大一個問題是，如何保證備份的一致性，其實關鍵還是在於FTWRL。對於非innodb表，在釋放鎖之前，需要將表備份完成。對於innodb表，需要確保多個線程都能拿到一致性位點，這個動作同樣要在持有全局鎖期間完成，因為此時數據庫沒有讀寫，可以保證位點一致。所以基本流程如下：
物理備份(Xtrabackup)
相對於邏輯備份利用查詢提取數據中的所有記錄，物理備份更直接，拷貝數據庫文件和日志來完成備份，因此速度會更快。當然，無論是開源的Mydumper還是官方最新的備份工具(5.7.11的mysqlpump)都支持了多線程備份，所以速度差異可能會進一步縮小，至少從目前生產環境來看，物理備份使用還是比較多的。由於Xtrabackup支持備份innodb表，實際生產環境中我們使用的工具是innobackupex，它是對xtrabackup的一層封裝。innobackupex
腳本用來備份非 InnoDB 表，同時會調用 xtrabackup
命令來備份 InnoDB 表，innobackupex的基本流程如下：
1.開啟redo日志拷貝線程，從最新的檢查點開始順序拷貝redo日志；
2.開啟idb文件拷貝線程，拷貝innodb表的數據
3.idb文件拷貝結束，通知調用FTWRL，獲取一致性位點
4.備份非innodb表(系統表)和frm文件
5.由於此時沒有新事務提交，等待redo日志拷貝完成
6.最新的redo日志拷貝完成後，相當於此時的innodb表和非innodb表數據都是最新的
7.獲取binlog位點，此時數據庫的狀態是一致的。
8.釋放鎖，備份結束。
Xtrabackup的改進
從前面介紹的邏輯備份和物理備份來看，無論是哪種備份工具，為了獲取一致性位點，都強依賴於FTWRL。這個鎖殺傷力非常大，因為持有鎖的這段時間，整個數據庫實質上不能對外提供寫服務的。此外，由於FTWRL需要關閉表，如有大查詢，會導致FTWRL等待，進而導致DML堵塞的時間變長。即使是備庫，也有SQL線程在復制來源於主庫的更新，上全局鎖時，會導致主備庫延遲。從前面的分析來看，FTWRL這把鎖持有的時間主要與非innodb表的數據量有關，如果非innodb表數據量很大，備份很慢，那麼持有鎖的時間就會很長。即使全部是innodb表，也會因為有mysql庫系統表存在，導致會鎖一定的時間。為了解決這個問題，Percona公司對Mysql的Server層做了改進，引入了BACKUP LOCK，具體而言，通過"LOCK
TABLES FOR BACKUP"命令來備份非innodb表數據；通過"LOCK BINLOG FOR BACKUP"來獲取一致性位點，盡量減少因為數據庫備份帶來的服務受損。我們看看采用這兩個鎖與FTWRL的區別：
LOCK TABLES FOR BACKUP
作用：備份數據
1.禁止非innodb表更新
2.禁止所有表的ddl
優化點：
1.不會被大查詢堵塞(關閉表)
2.不會堵塞innodb表的讀取和更新，這點非常重要，對於業務表全部是innodb的情況，則備份過程中DML完全不受損
UNLOCK
TABLES
LOCK BINLOG FOR BACKUP
作用：獲取一致性位點。
1.禁止對位點更新的操作
優化點：
1.允許DDl和更新，直到寫binlog為止。
UNLOCK
BINLOG
參考文檔
http://mysql.taobao.org/monthly/2016/03/07/
https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/
http://www.wtoutiao.com/p/1cbstSx.html
http://www.wtoutiao.com/p/10cEnZ7.html
http://www.wtoutiao.com/p/125vVWi.html
http://www.wtoutiao.com/p/120AXSH.html
http://www.cnblogs.com/cchust/p/4603599.html
