前言：

在確定備份策略和選擇備份工具時，應從業(yè)務的RTO和RPO出發(fā)，結合存儲成本綜合考慮。數(shù)據(jù)庫備份的重要性毋庸置疑，可以說，它是數(shù)據(jù)安全的最后一道防線。鑒于此，對于備份，我們通常會做以下要求：

一、多地部署

對于核心數(shù)據(jù)庫，我們通常有兩地三中心的部署要求。對于備份來說，也是如此。一個備份應該有多個副本，每個副本存儲在不同區(qū)域。

多介質部署：

一個備份的多個副本應存儲在不同介質上，如磁盤和磁帶，防止單一介質失效。

定期檢查備份的有效性：

備份只是在做正確的事情，有沒有把事情做對，還得依靠備份的有效性檢查。前兩項，在條件允許的情況下，建議做。第三項必須做。

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

• 備份的常見分類。
• MySQL中的備份工具。
• mysqlbackup與mysqldump的備份恢復速度對比。
• 如何檢測備份的有效性。
• RTO和RPO 。

二、備份的常見分類

1、物理備份 VS 邏輯備份

1）物理備份

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

① 優(yōu)點

• 備份、恢復速度快。尤其是恢復速度，直接關系著數(shù)據(jù)庫服務的RTO。
• 無需實例在線。在實例關閉的情況下，可直接拷貝文件，不用擔心備份的一致性。關閉實例進行備份，也稱之為 “冷備” 。

② 缺點

• 備份文件大。
• 恢復時，對平臺、操作系統(tǒng)、MySQL版本有要求，必須一致或兼容。
• 只能在本地發(fā)起備份。
• 因為是拷貝物理文件，即使文件中存在很多“空洞”（大量DELETE導致），也無法通過恢復來收縮 。
• 對表的存儲引擎有要求，無法備份MEMORY表。

2）邏輯備份

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

① 優(yōu)點

• 可移植性強?；謴蜁r，對平臺、操作系統(tǒng)、MySQL版本無要求。
• 靈活。尤其是在恢復時，可只恢復一個庫或一張表。
• 對表的存儲引擎沒有要求，任何類型的表都可備份。
• 備份文件較小。
• 可遠程發(fā)起備份。
• 恢復后，能有效收縮空間。

② 缺點

• 備份、恢復速度慢。實際上，單論備份速度，多線程備份其實也不慢。但恢復速度呢，即使是多線程恢復，也很慢。
• 備份會"污染"Buffer Pool。業(yè)務熱點數(shù)據(jù)會被備份數(shù)據(jù)驅逐出Buffer Pool。

2、離線備份 VS 在線備份

離線備份，又可稱之為 "冷備"，即實例關閉的情況下進行的備份。此時，只能進行物理備份，即全量拷貝物理文件。在線備份，又可稱之為 "熱備"，即實例運行過程中進行的備份。此時，既可進行物理備份，又可進行邏輯備份。因對業(yè)務侵入較小，線上一般使用在線備份。

3、全量備份 VS 增量備份

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

通常來說，基于物理備份來實現(xiàn)增量備份較為簡單，以MySQL為例，只需判斷數(shù)據(jù)頁的LSN是否發(fā)生了變化。而對于邏輯備份，就很難實現(xiàn)，如常見的基于某個時間字段來進行增量備份，但其實，很難保證某個時間段之前的數(shù)據(jù)不被修改或刪除。

三、MySQL中的備份工具

1、物理備份

物理備份相關的工具有：

1）XtraBackup

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

XtraBackup目前維護的大版本有兩個：

• XtraBackup 2.4，適用于MySQL 5.6和5.7。
• XtraBackup 8.0。適用于 MySQL 8.0。

之所以要維護兩個版本，是因為MySQL 8.0中的redo log和數(shù)據(jù)字典的格式發(fā)生了變化。

2）mysqlbackup

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

3）Clone Plugin

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

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

2、邏輯備份

邏輯備份相關的工具有：

1）mysqldump

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

2）mydumper

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

3）mysqlpump

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

4）MySQL Shell

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

這個工具對備份實例和恢復實例的版本有要求：備份實例 >= 5.6，恢復實例 >= 5.7。

5）SELECT ... INTO OUTFILE

SQL命令，可將表記錄直接導出到文件中。

下面說說這幾個工具的異同點：

• 從實現(xiàn)原理來看，mysqldump、 mydumper、mysqlpump、 MySQL Shell可歸為一類，本質上都是通過SELECT * FROM TABLE的方式備份數(shù)據(jù)，只不過在此基礎上，通過全局讀鎖 + REPEATABLE READ事務隔離級別，實現(xiàn)了數(shù)據(jù)庫的一致性備份。
• SELECT ... INTO OUTFILE 充其量只是一個命令，算不上工具，更不用說數(shù)據(jù)庫的一致性備份。
• 從導出的內(nèi)容來看，mysqldump、mydumper、mysqlpump 會以INSERT語句的形式保存?zhèn)浞萁Y果，如：

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

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

1       aaa
2       bbb
3       ccc

在恢復，各個工具對應的恢復工具也不一樣。具體來說，

mysqldump、mysqlpump對應的恢復工具是mysql客戶端，所以是單線程恢復。mydumper對應的恢復工具是myloader，支持多線程恢復。util.dumpInstance()對應的恢復工具是util.loadDump()，該工具實際調(diào)用的是LOAD DATA LOCAL INFILE命令，支持多線程恢復。SELECT ... INTO OUTFILE對應的恢復命令是LOAD DATA。

四、mysqlbackup VS mysqldump

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

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

第二張圖比較的是恢復時間，mysqldump是mysqlbackup的80倍。

借此，我們也能看到邏輯備份工具相對于物理備份工具在備份、還原速度上的差距。不過可惜的是，這里沒有測試mydumper。畢竟，針對數(shù)據(jù)量較大的實例，如果一定要使用邏輯備份，大家一般傾向于使用mydumper，而不是mysqldump。

五、如何檢測備份的有效性

為什么要檢測備份的有效性，原因主要有兩個：

• 驗證整個備份環(huán)節(jié)的可靠性。包括備份參數(shù)是否完備，備份集是否有效，備份介質是否損壞等。
• 通過檢查備份的有效性，搭建一套完整的自動化恢復體系。

很多時候，影響數(shù)據(jù)庫恢復時間的并不是備份集太老，而是手動恢復過程中，因為命令、環(huán)境、流程的不熟悉，所帶來的額外耗時。

如何檢測備份的有效性，常用的方法有三個：

• （1）基于備份恢復實例，看實例能否起來。并在此基礎上，進行隨機查詢。

這種檢測方法最簡單。一般來說，實例能起來，且隨機查詢也沒問題，就意味著這個備份集是可用的。但備份集可用，并不意味著這個備份集能滿足我們的需求，譬如常見的，搭建從庫。而且一些常見的問題，如備份中斷、參數(shù)沒指定準確，也無法通過這種方式檢測出來。

• （2）在1的基礎上，建立復制。

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

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

如果檢查結果沒問題，則意味著主從數(shù)據(jù)是一致的，也就間接證明了備份的有效性。但因為pt-table-checksum在運行的過程中，會在chunk級別對表加S鎖，對更新頻繁的業(yè)務，還是有一定的影響。一般來說，線上使用方法2足矣。方法3，因為要檢查主從數(shù)據(jù)的一致性，耗時相對較久，如果要檢測的備份集很多，反而會影響檢測的效率。

六、RTO 和 RPO

衡量一個數(shù)據(jù)中心的容災能力時，有兩個常用的指標：

• RTO：Recovery Time Objective，恢復時間目標。

指的是災難發(fā)生后，必須在這個時間內(nèi)恢復數(shù)據(jù)。在恢復數(shù)據(jù)的這段時間內(nèi)，服務是不可用的，所以RTO也是服務可允許的最大不可用時間。如果我們要求服務的最大不可用時間是30分鐘，那么RTO就是30分鐘。RTO 越小，代表容災系統(tǒng)的恢復能力越強。

• RPO：Recovery Point Objective，數(shù)據(jù)恢復點目標。

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

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

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

RTO、RPO與災難在時間軸上的關系如下圖所示：

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

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

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

1、RTO

• 增加備份頻率，縮短備份周期。
• 選擇物理備份，而不是邏輯備份。
• 添加延遲從庫。
• 恢復流程的自動化。

2、RPO

• 增加備份頻率，縮短備份周期。
• 搭建Binlog Server備份Binlog。當出現(xiàn)故障時，我們可以基于備份和Binlog做基于時間點的恢復。
• 添加延遲從庫。

七、總結

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

從RPO的角度出發(fā)，應盡量增加備份頻率，縮短備份周期。但 every coin has two sides，使用物理備份或者增加備份頻率，無疑會增加存儲成本。所以，在確定備份策略和選擇備份工具時，應從業(yè)務的RTO和RPO出發(fā)，結合存儲成本綜合考慮。大多數(shù)公司會采取一個統(tǒng)一的備份策略，如一天一個全備。雖然災難情況很少出現(xiàn)，開發(fā)和DBA童鞋也應充分理解到這里面的風險，并制定相應的預案及業(yè)務兜底方案。另外，對于線上核心業(yè)務，如果只有備份，還是很難有效降低數(shù)據(jù)庫服務的RTO和RPO，建議部署延遲從庫。

到此這篇關于MySQL選擇合適的備份策略和備份工具的文章就介紹到這了,更多相關MySQL備份策略和工具內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論