MySQL的幾種備份方法

下文內(nèi)容主要給大家?guī)?a title="MySQL" target="_blank" href="http://kemok4.com/mysql/">MySQL的幾種備份方法，所講到的知識，與書籍略有不同，都是億速云專業(yè)技術(shù)人員在與用戶接觸過程中，總結(jié)出來的，具有一定的經(jīng)驗分享價值，希望給廣大讀者帶來幫助。

備份是數(shù)據(jù)安全的最后一道防線，對于任何數(shù)據(jù)丟失的場景，備份雖然不一定能恢復(fù)百分之百的數(shù)據(jù)(取決于備份周期)，但至少能將損失降到最低。衡量備份恢復(fù)有兩個重要的指標(biāo)：恢復(fù)點目標(biāo)(RPO)和恢復(fù)時間目標(biāo)(RTO)，前者重點關(guān)注能恢復(fù)到什么程度，而后者則重點關(guān)注恢復(fù)需要多長時間。這篇文章主要討論MySQL的備份方案，重點介紹幾種備份方式的原理，包括文件系統(tǒng)快照(LVM)，邏輯備份工具Mysqldump，Mydumper，以及物理備份工具Xtrabackup，同時會詳細(xì)講解幾種方案的優(yōu)缺點，以及可能遇到的問題下載地址  。

冷備份
     最簡單的備份方式就是，關(guān)閉MySQL云服務(wù)器，然后將data目錄下面的所有文件進行拷貝保存，需要恢復(fù)時，則將目錄拷貝到需要恢復(fù)的機器即可。這種方式確實方便，但是在生產(chǎn)環(huán)境中基本沒什么作用。因為所有的機器都是要提供服務(wù)的，即使是Slave有時候也需要提供只讀服務(wù)，所以關(guān)閉MySQL停服備份是不現(xiàn)實的。與冷備份相對應(yīng)的一個概念是熱備份，所謂熱備份是在不影響MySQL對外服務(wù)的情況下，進行備份，熱備份是這篇文章討論的重點。

快照備份
     首先要介紹的熱備份是快照備份，快照備份是指通過文件系統(tǒng)支持的快照功能對數(shù)據(jù)庫進行備份。備份的原理是將所有的數(shù)據(jù)庫文件放在同一分區(qū)中，然后對該分區(qū)執(zhí)行快照工作，對于Linux而言，需要通過LVM(Logical Volumn Manager)來實現(xiàn)。LVM使用寫時復(fù)制(copy-on-write)技術(shù)來創(chuàng)建快照，例如，對整個卷的某個瞬間的邏輯副本，類似于數(shù)據(jù)庫中的innodb存儲引擎的MVCC，只不過LVM的快照在文件系統(tǒng)層面，而MVCC在數(shù)據(jù)庫層面，而且僅支持innodb存儲引擎。LVM有一個快照預(yù)留區(qū)域，如果原始卷數(shù)據(jù)有變化時，LVM保證在任何變更寫入之前，會復(fù)制受影響塊到快照預(yù)留區(qū)域。簡單來說，快照區(qū)域內(nèi)保留了快照點開始時的一致的所有old數(shù)據(jù)。對于更新很少的數(shù)據(jù)庫，快照也會非常小。對于MySQL而言，為了使用快照備份，需要將數(shù)據(jù)文件，日志文件都放在一個邏輯卷中，然后對該卷快照備份即可。由于快照備份，只能本地，因此，如果本地的磁盤損壞，則快照也就損壞了?？煺諅浞莞蛴趯φ`操作防范，可以將數(shù)據(jù)庫迅速恢復(fù)到快照產(chǎn)生的時間點，然后結(jié)合二進制日志可以恢復(fù)到指定的時間點。

邏輯備份
      冷備份和快照備份由于其弊端在生產(chǎn)環(huán)境中很少使用，使用更多是MySQL自帶的邏輯備份和物理備份工具，這節(jié)主要講邏輯備份，MySQL官方提供了Mysqldump邏輯備份工具，雖然已經(jīng)足夠好，但存在單線程備份慢的問題。在社區(qū)提供了更優(yōu)秀的邏輯備份工具mydumper，它的優(yōu)勢主要體現(xiàn)在多線程備份，備份速度更快。

Mysqldump
Mysqldump用于備份，不得不提兩個關(guān)鍵的參數(shù)：
--single-transaction：在開始備份前，執(zhí)行start transaction命令，以此來獲取一致性備份，該參數(shù)僅對innodb存儲引擎有效。
--master-data=2：主要用于記錄一致性備份的位點。
理解Mysqldump工作原理，一定要將事務(wù)表(innodb)和非事務(wù)表(比如myisam)區(qū)別對待，因為備份的流程與此息息相關(guān)。而且，到目前為止，我們也無法規(guī)避myisam表，即使我們的所有業(yè)務(wù)表都是innodb，因為mysql庫中系統(tǒng)表仍然采用的myisam表。備份的基本流程如下：
1.調(diào)用FTWRL(flush tables with read lock)，全局禁止讀寫
2.開啟快照讀，獲取此時的快照(僅對innodb表起作用)
3.備份非innodb表數(shù)據(jù)(*.frm,*.myi,*.myd等)
4.非innodb表備份完畢后，釋放FTWRL鎖
5.逐一備份innodb表數(shù)據(jù)
6.備份完成。
整個過程，可以參考我同事的一張圖，但他的這張圖只考慮innodb表的備份情況，實際上在unlock tables執(zhí)行完畢之前，非innodb表已經(jīng)備份完畢，后面的t1,t2和t3實質(zhì)都是innodb表，而且5.6的mysqldump利用保存點機制，每備份完一個表就將一個表上的MDL鎖釋放，避免對一張表鎖更長的時間。這里可以參考我之前的blog：FLUSH TABLE WITH READ LOCK
大家可能有一個疑問，為啥備份innodb表之前，就已經(jīng)將鎖釋放掉了，這實際上是利用了innodb引擎的MVCC機制，開啟快照讀后，就能獲取那個時間的一致的數(shù)據(jù)，無論需要備份多長時間，直到整個事務(wù)結(jié)束(commit)為止。 

Mydumper
     Mydumper原理與Mysqldump原理類似，最大的區(qū)別是引入了多線程備份，每個備份線程備份一部分表，當(dāng)然并發(fā)粒度可以到行級，達(dá)到多線程備份的目的。這里要解決最大一個問題是，如何保證備份的一致性，其實關(guān)鍵還是在于FTWRL。對于非innodb表，在釋放鎖之前，需要將表備份完成。對于innodb表，需要確保多個線程都能拿到一致性位點，這個動作同樣要在持有全局鎖期間完成，因為此時數(shù)據(jù)庫沒有讀寫，可以保證位點一致。所以基本流程如下：

物理備份(Xtrabackup)
      相對于邏輯備份利用查詢提取數(shù)據(jù)中的所有記錄，物理備份更直接，拷貝數(shù)據(jù)庫文件和日志來完成備份，因此速度會更快。當(dāng)然，無論是開源的Mydumper還是官方最新的備份工具(5.7.11的mysqlpump)都支持了多線程備份，所以速度差異可能會進一步縮小，至少從目前生產(chǎn)環(huán)境來看，物理備份使用還是比較多的。由于Xtrabackup支持備份innodb表，實際生產(chǎn)環(huán)境中我們使用的工具是innobackupex，它是對xtrabackup的一層封裝。innobackupex 腳本用來備份非 InnoDB 表，同時會調(diào)用 xtrabackup 命令來備份 InnoDB 表，innobackupex的基本流程如下：
1.開啟redo日志拷貝線程，從最新的檢查點開始順序拷貝redo日志；
2.開啟idb文件拷貝線程，拷貝innodb表的數(shù)據(jù)
3.idb文件拷貝結(jié)束，通知調(diào)用FTWRL，獲取一致性位點
4.備份非innodb表(系統(tǒng)表)和frm文件
5.由于此時沒有新事務(wù)提交，等待redo日志拷貝完成
6.最新的redo日志拷貝完成后，相當(dāng)于此時的innodb表和非innodb表數(shù)據(jù)都是最新的
7.獲取binlog位點，此時數(shù)據(jù)庫的狀態(tài)是一致的。
8.釋放鎖，備份結(jié)束。

Xtrabackup的改進
     從前面介紹的邏輯備份和物理備份來看，無論是哪種備份工具，為了獲取一致性位點，都強依賴于FTWRL。這個鎖殺傷力非常大，因為持有鎖的這段時間，整個數(shù)據(jù)庫實質(zhì)上不能對外提供寫服務(wù)的。此外，由于FTWRL需要關(guān)閉表，如有大查詢，會導(dǎo)致FTWRL等待，進而導(dǎo)致DML堵塞的時間變長。即使是備庫，也有SQL線程在復(fù)制來源于主庫的更新，上全局鎖時，會導(dǎo)致主備庫延遲。從前面的分析來看，F(xiàn)TWRL這把鎖持有的時間主要與非innodb表的數(shù)據(jù)量有關(guān)，如果非innodb表數(shù)據(jù)量很大，備份很慢，那么持有鎖的時間就會很長。即使全部是innodb表，也會因為有mysql庫系統(tǒng)表存在，導(dǎo)致會鎖一定的時間。為了解決這個問題，Percona公司對Mysql的Server層做了改進，引入了BACKUP LOCK，具體而言，通過"LOCK TABLES FOR BACKUP"命令來備份非innodb表數(shù)據(jù)；通過"LOCK BINLOG FOR BACKUP"來獲取一致性位點，盡量減少因為數(shù)據(jù)庫備份帶來的服務(wù)受損。我們看看采用這兩個鎖與FTWRL的區(qū)別：

LOCK TABLES FOR BACKUP
作用：備份數(shù)據(jù)
1.禁止非innodb表更新
2.禁止所有表的ddl
優(yōu)化點：
1.不會被大查詢堵塞(關(guān)閉表)
2.不會堵塞innodb表的讀取和更新，這點非常重要，對于業(yè)務(wù)表全部是innodb的情況，則備份過程中DML完全不受損
UNLOCK TABLES

LOCK BINLOG FOR BACKUP
作用：獲取一致性位點。
1.禁止對位點更新的操作
優(yōu)化點：
1.允許DDl和更新，直到寫binlog為止。
UNLOCK BINLOG

對于以上關(guān)于MySQL的幾種備份方法，如果大家還有更多需要了解的可以持續(xù)關(guān)注我們億速云的行業(yè)推新，如需獲取專業(yè)解答，可在官網(wǎng)聯(lián)系售前售后的，希望該文章可給大家?guī)硪欢ǖ闹R更新。