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

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

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

?

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

?

?

?

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

?

?

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

?

?

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

?

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

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

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