數(shù)據(jù)庫備份的重要性毋庸置疑，可以說，它是數(shù)據(jù)安全的最后一道防線。鑒于此，對(duì)于備份，我們通常會(huì)做以下要求：

• 多地部署

  對(duì)于核心數(shù)據(jù)庫，我們通常有兩地三中心的部署要求。對(duì)于備份來說，也是如此。

  一個(gè)備份應(yīng)該有多個(gè)副本，每個(gè)副本存儲(chǔ)在不同區(qū)域。

• 多介質(zhì)部署

  一個(gè)備份的多個(gè)副本應(yīng)存儲(chǔ)在不同介質(zhì)上，如磁盤和磁帶，防止單一介質(zhì)失效。

• 定期檢查備份的有效性

  備份只是在做正確的事情，有沒有把事情做對(duì)，還得依靠備份的有效性檢查。

前兩項(xiàng)，在條件允許的情況下，建議做。第三項(xiàng)必須做。

接下來，我們聊聊備份的相關(guān)話題，主要包括以下五方面的內(nèi)容：

1. 備份的常見分類。
2. MySQL中的備份工具。
3. mysqlbackup與mysqldump的備份恢復(fù)速度對(duì)比。
4. 如何檢測(cè)備份的有效性。
5. RTO和RPO 。

備份的常見分類

物理備份 VS 邏輯備份

物理備份，顧名思義，就是備份物理文件。其優(yōu)缺點(diǎn)如下：

優(yōu)點(diǎn)：

• 備份、恢復(fù)速度快。

  尤其是恢復(fù)速度，直接關(guān)系著數(shù)據(jù)庫服務(wù)的RTO。

• 無需實(shí)例在線。

  在實(shí)例關(guān)閉的情況下，可直接拷貝文件，不用擔(dān)心備份的一致性。

  關(guān)閉實(shí)例進(jìn)行備份，也稱之為 “冷備” 。

缺點(diǎn)：

• 備份文件大。

• 恢復(fù)時(shí)，對(duì)平臺(tái)、操作系統(tǒng)、MySQL版本有要求，必須一致或兼容。

• 只能在本地發(fā)起備份。

• 因?yàn)槭强截愇锢砦募词刮募写嬖诤芏唷翱斩础保ù罅緿ELETE導(dǎo)致），也無法通過恢復(fù)來收縮 。

• 對(duì)表的存儲(chǔ)引擎有要求，無法備份MEMORY表。

邏輯備份，備份表的邏輯記錄。其優(yōu)缺點(diǎn)如下：

優(yōu)點(diǎn)：

• 可移植性強(qiáng)?；謴?fù)時(shí)，對(duì)平臺(tái)、操作系統(tǒng)、MySQL版本無要求。

• 靈活。尤其是在恢復(fù)時(shí)，可只恢復(fù)一個(gè)庫或一張表。

• 對(duì)表的存儲(chǔ)引擎沒有要求，任何類型的表都可備份。

• 備份文件較小。

• 可遠(yuǎn)程發(fā)起備份。

• 恢復(fù)后，能有效收縮空間。

缺點(diǎn)：

• 備份、恢復(fù)速度慢。

  實(shí)際上，單論備份速度，多線程備份其實(shí)也不慢。但恢復(fù)速度呢，即使是多線程恢復(fù)，也很慢。

• 備份會(huì)"污染"Buffer Pool。

  業(yè)務(wù)熱點(diǎn)數(shù)據(jù)會(huì)被備份數(shù)據(jù)驅(qū)逐出Buffer Pool 。

離線備份 VS 在線備份

離線備份，又可稱之為 "冷備"，即實(shí)例關(guān)閉的情況下進(jìn)行的備份。此時(shí)，只能進(jìn)行物理備份，即全量拷貝物理文件。

在線備份，又可稱之為 "熱備"，即實(shí)例運(yùn)行過程中進(jìn)行的備份。此時(shí)，既可進(jìn)行物理備份，又可進(jìn)行邏輯備份。

因?qū)I(yè)務(wù)侵入較小，線上一般使用在線備份。

全量備份 VS 增量備份

全量備份，即備份整個(gè)實(shí)例的全量數(shù)據(jù)。

增量備份，即只備份上次備份以來，那些發(fā)生了"變化"的數(shù)據(jù)。

通常來說，基于物理備份來實(shí)現(xiàn)增量備份較為簡單，以MySQL為例，只需判斷數(shù)據(jù)頁的LSN是否發(fā)生了變化。

而對(duì)于邏輯備份，就很難實(shí)現(xiàn)，如常見的基于某個(gè)時(shí)間字段來進(jìn)行增量備份，但其實(shí)，很難保證某個(gè)時(shí)間段之前的數(shù)據(jù)不被修改或刪除。

MySQL中的備份工具

物理備份

物理備份相關(guān)的工具有：

• XtraBackup

  Percona公司開源的備份工具，適用于MySQL、MariaDB、Percona Server。

  https://www.percona.com/software/mysql-database/percona-xtrabackup

  XtraBackup目前維護(hù)的大版本有兩個(gè)：

  1. XtraBackup 2.4，適用于MySQL 5.6和5.7。

  2. XtraBackup 8.0。適用于 MySQL 8.0。

  之所以要維護(hù)兩個(gè)版本，是因?yàn)镸ySQL 8.0中的redo log和數(shù)據(jù)字典的格式發(fā)生了變化。

• mysqlbackup

  MySQL企業(yè)級(jí)備份工具（ MySQL Enterprise Backup ），適用于MySQL企業(yè)版。

  https://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/mysqlbackup.html

• Clone Plugin

  MySQL 8.0.17引入的克隆插件。初衷是為了方便Group Replication添加新的節(jié)點(diǎn)。有了Clone Plugin，我們也能很方便的搭建一個(gè)從庫，無需借助其它備份工具。

三者的實(shí)現(xiàn)原理基本相同，都是在備份的過程中，拷貝物理文件和redo log ，最后，再利用InnoDB Crash Recovery，將物理文件恢復(fù)到備份結(jié)束時(shí)的一致性狀態(tài)。

邏輯備份

邏輯備份相關(guān)的工具有：

• mysqldump

  MySQL安裝包自帶的備份工具，單線程備份。

• mydumper

  由Facebook、SkySQL、Oracle和Percona開發(fā)人員維護(hù)的一個(gè)多線程備份工具，可實(shí)現(xiàn)行級(jí)別的并行備份。

• https://github.com/maxbube/mydumper

• mysqlpump

  MySQL 5.7引入的備份工具，可實(shí)現(xiàn)表級(jí)別的并行備份。

• MySQL Shell

  MySQL Shell 8.0.21引入了一個(gè)工具-util.dumpInstance()，可實(shí)現(xiàn)行級(jí)別的并行備份。

  這個(gè)工具對(duì)備份實(shí)例和恢復(fù)實(shí)例的版本有要求：備份實(shí)例 >= 5.6，恢復(fù)實(shí)例 >= 5.7。

• SELECT ... INTO OUTFILE

  SQL命令，可將表記錄直接導(dǎo)出到文件中。

下面說說這幾個(gè)工具的異同點(diǎn)：

1. 從實(shí)現(xiàn)原理來看，mysqldump、 mydumper、mysqlpump、 MySQL Shell可歸為一類，本質(zhì)上都是通過SELECT * FROM TABLE的方式備份數(shù)據(jù)，只不過在此基礎(chǔ)上，通過全局讀鎖 + REPEATABLE READ事務(wù)隔離級(jí)別，實(shí)現(xiàn)了數(shù)據(jù)庫的一致性備份。

2. SELECT ... INTO OUTFILE 充其量只是一個(gè)命令，算不上工具，更不用說數(shù)據(jù)庫的一致性備份。

3. 從導(dǎo)出的內(nèi)容來看，mysqldump、mydumper、mysqlpump 會(huì)以INSERT語句的形式保存?zhèn)浞萁Y(jié)果，如，

   INSERT INTO `t1` VALUES (1,'aaa'),(2,'bbb'),(3,'ccc');
   

   而 MySQL Shell和SELECT ... INTO OUTFILE 是以CSV格式的形式保存?zhèn)浞萁Y(jié)果，如，

   1       aaa
   2       bbb
   3       ccc
   

4. 在恢復(fù)，各個(gè)工具對(duì)應(yīng)的恢復(fù)工具也不一樣。具體來說，

   mysqldump、mysqlpump對(duì)應(yīng)的恢復(fù)工具是mysql客戶端，所以是單線程恢復(fù)。

   mydumper對(duì)應(yīng)的恢復(fù)工具是myloader，支持多線程恢復(fù)。

   util.dumpInstance()對(duì)應(yīng)的恢復(fù)工具是util.loadDump()，該工具實(shí)際調(diào)用的是LOAD DATA LOCAL INFILE命令，支持多線程恢復(fù)。

   SELECT ... INTO OUTFILE對(duì)應(yīng)的恢復(fù)命令是LOAD DATA。

mysqlbackup VS mysqldump

下面是MySQL官方提供的一組數(shù)據(jù)，對(duì)比了mysqlbackup和mysqldump備份恢復(fù)時(shí)間。

第一張圖比較的是備份時(shí)間，mysqldump是mysqlbackup的49倍。

第二張圖比較的是恢復(fù)時(shí)間，mysqldump是mysqlbackup的80倍。

借此，我們也能看到邏輯備份工具相對(duì)于物理備份工具在備份、還原速度上的差距。

不過可惜的是，這里沒有測(cè)試mydumper。

畢竟，針對(duì)數(shù)據(jù)量較大的實(shí)例，如果一定要使用邏輯備份，大家一般傾向于使用mydumper，而不是mysqldump。

如何檢測(cè)備份的有效性

為什么要檢測(cè)備份的有效性，原因主要有兩個(gè)：

1. 驗(yàn)證整個(gè)備份環(huán)節(jié)的可靠性。

   包括備份參數(shù)是否完備，備份集是否有效，備份介質(zhì)是否損壞等。

2. 通過檢查備份的有效性，搭建一套完整的自動(dòng)化恢復(fù)體系。

   很多時(shí)候，影響數(shù)據(jù)庫恢復(fù)時(shí)間的并不是備份集太老，而是手動(dòng)恢復(fù)過程中，因?yàn)槊?、環(huán)境、流程的不熟悉，所帶來的額外耗時(shí)。

如何檢測(cè)備份的有效性，常用的方法有三個(gè)：

1. 基于備份恢復(fù)實(shí)例，看實(shí)例能否起來。并在此基礎(chǔ)上，進(jìn)行隨機(jī)查詢。

   這種檢測(cè)方法最簡單。

   一般來說，實(shí)例能起來，且隨機(jī)查詢也沒問題，就意味著這個(gè)備份集是可用的。

   但備份集可用，并不意味著這個(gè)備份集能滿足我們的需求，譬如常見的，搭建從庫。

   而且一些常見的問題，如備份中斷、參數(shù)沒指定準(zhǔn)確，也無法通過這種方式檢測(cè)出來。

2. 在1的基礎(chǔ)上，建立復(fù)制。

   如果從庫在追主庫的過程中，沒有報(bào)錯(cuò)，大概率意味著主從數(shù)據(jù)是一致的。當(dāng)然，也只是大概率，并不是100%。

3. 在2的基礎(chǔ)上，利用pt-table-checksum檢查主從數(shù)據(jù)的一致性。

   如果檢查結(jié)果沒問題，則意味著主從數(shù)據(jù)是一致的，也就間接證明了備份的有效性。

   但因?yàn)閜t-table-checksum在運(yùn)行的過程中，會(huì)在chunk級(jí)別對(duì)表加S鎖，對(duì)更新頻繁的業(yè)務(wù)，還是有一定的影響。

一般來說，線上使用方法2足矣。

方法3，因?yàn)橐獧z查主從數(shù)據(jù)的一致性，耗時(shí)相對(duì)較久，如果要檢測(cè)的備份集很多，反而會(huì)影響檢測(cè)的效率。

RTO 和 RPO

衡量一個(gè)數(shù)據(jù)中心的容災(zāi)能力時(shí)，有兩個(gè)常用的指標(biāo)：

• RTO：Recovery Time Objective，恢復(fù)時(shí)間目標(biāo)。

  指的是災(zāi)難發(fā)生后，必須在這個(gè)時(shí)間內(nèi)恢復(fù)數(shù)據(jù)。

  在恢復(fù)數(shù)據(jù)的這段時(shí)間內(nèi)，服務(wù)是不可用的，所以RTO也是服務(wù)可允許的最大不可用時(shí)間。如果我們要求服務(wù)的最大不可用時(shí)間是30分鐘，那么RTO就是30分鐘。

  RTO 越小，代表容災(zāi)系統(tǒng)的恢復(fù)能力越強(qiáng)。

• RPO：Recovery Point Objective，數(shù)據(jù)恢復(fù)點(diǎn)目標(biāo)。

  指的是災(zāi)難發(fā)生后，數(shù)據(jù)可以恢復(fù)到的時(shí)間點(diǎn)。

  譬如，我有一個(gè)系統(tǒng)，每天0點(diǎn)進(jìn)行一次全備。當(dāng)系統(tǒng)出現(xiàn)故障后，會(huì)基于上一次的備份來恢復(fù)。如果系統(tǒng)在凌晨3點(diǎn)出現(xiàn)故障，我們會(huì)丟失3個(gè)小時(shí)的數(shù)據(jù)。極端情況下，系統(tǒng)在23:59出現(xiàn)故障，我們會(huì)丟失24個(gè)小時(shí)的數(shù)據(jù)。這里的24小時(shí)就是這個(gè)系統(tǒng)的RPO 。

  RPO越小，代表系統(tǒng)越能保證數(shù)據(jù)的完整性。

RTO、RPO與災(zāi)難在時(shí)間軸上的關(guān)系如下圖所示：

可以看到，RPO針對(duì)的是數(shù)據(jù)丟失，RTO針對(duì)的是服務(wù)宕機(jī)時(shí)間，兩者之間沒有必然的聯(lián)系。

最理想的情況是RTO和RPO都為0，這就意味著當(dāng)災(zāi)難發(fā)生時(shí)，系統(tǒng)會(huì)立即恢復(fù)，而且數(shù)據(jù)不會(huì)丟失。當(dāng)然，RTO、RPO越小，需要投入的成本也越高。

具體到MySQL中，為了降低RTO和RPO，我們可以從以下幾個(gè)方面著手：

RTO

1. 增加備份頻率，縮短備份周期。

2. 選擇物理備份，而不是邏輯備份。

3. 添加延遲從庫。

4. 恢復(fù)流程的自動(dòng)化。

RPO

1. 增加備份頻率，縮短備份周期。

2. 搭建Binlog Server備份Binlog。當(dāng)出現(xiàn)故障時(shí)，我們可以基于備份和Binlog做基于時(shí)間點(diǎn)的恢復(fù)。

3. 添加延遲從庫。

總結(jié)

從RTO的角度出發(fā)，應(yīng)盡量選擇物理備份，而不是邏輯備份。如果要使用邏輯備份，應(yīng)盡量選擇多線程備份工具和多線程恢復(fù)工具。

從RPO的角度出發(fā)，應(yīng)盡量增加備份頻率，縮短備份周期。

但 every coin has two sides，使用物理備份或者增加備份頻率，無疑會(huì)增加存儲(chǔ)成本。

所以，在確定備份策略和選擇備份工具時(shí)，應(yīng)從業(yè)務(wù)的RTO和RPO出發(fā)，結(jié)合存儲(chǔ)成本綜合考慮。

大多數(shù)公司會(huì)采取一個(gè)統(tǒng)一的備份策略，如一天一個(gè)全備。雖然災(zāi)難情況很少出現(xiàn)，開發(fā)和DBA童鞋也應(yīng)充分理解到這里面的風(fēng)險(xiǎn)，并制定相應(yīng)的預(yù)案及業(yè)務(wù)兜底方案。

另外，對(duì)于線上核心業(yè)務(wù)，如果只有備份，還是很難有效降低數(shù)據(jù)庫服務(wù)的RTO和RPO，建議部署延遲從庫。