MySQL備份原理詳解

     備份是數據安全的最後一道防線，對於任何數據丟失的場景，備份雖然不必定能恢復百分之百的數據(取決於備份週期)，但至少能將損失降到最低。衡量備份恢復有兩個重要的指標：恢復點目標(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機制，開啓快照讀後(

set transaction isolation level repeatable read)，就能獲取那個時間的一致的數據，不管須要備份多長時間，直到整個事務結束(commit)爲止。固然，這個RR級別的快照，對錶的元數據也有要求，由於邏輯備份表是一個個進行的，若是在備份某個表以前，這個表作了DDL操做(此時備份事務暫時尚未加MDL鎖)，後續再備份這個表時，就會由於表定義不一致而報錯(Table definition has changed, please retry transaction)。因此總地來講，經過保存點機制，能夠有效減小DDL操做的限制，可是也不能徹底消除因爲DDL操做致使的備份失敗問題。

 

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.釋放鎖，備份結束。

說明：咱們知道MySQL裏面有個double-write爲了防止寫的時候頁斷裂，那麼備份讀的時候，有沒有可能也只一半的page呢？這個實際上是有可能的，所以，咱們在拷貝page的時候，須要對page算checksum，若是checksum不符合預期，咱們認爲拷貝的頁面不完整(這種狀況可能發生在你在讀頁面，然後臺線程正在刷髒)，須要重試。因此，最終也能保證數據的一致性。

 

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