MySQL選擇合適的備份策略和備份工具

2022-05-31 14:02:51

一、多地部署

對於核心資料庫，我們通常有兩地三中心的部署要求。對於備份來說，也是如此。一個備份應該有多個副本，每個副本儲存在不同區域。

多媒介部署：

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

定期檢查備份的有效性：

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

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

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

二、備份的常見分類

1、物理備份 VS 邏輯備份

1）物理備份

顧名思義，就是備份物理檔案。其優缺點如下：

① 優點

備份、恢復速度快。尤其是恢復速度，直接關係著資料庫服務的RTO。
無需範例線上。在範例關閉的情況下，可直接拷貝檔案，不用擔心備份的一致性。關閉範例進行備份，也稱之為 “冷備” 。

② 缺點

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

2）邏輯備份

備份表的邏輯記錄。其優缺點如下：

① 優點

可移植性強。恢復時，對平臺、作業系統、MySQL版本無要求。
靈活。尤其是在恢復時，可只恢復一個庫或一張表。
對錶的儲存引擎沒有要求，任何型別的表都可備份。
備份檔案較小。
可遠端發起備份。
恢復後，能有效收縮空間。

② 缺點

備份、恢復速度慢。實際上，單論備份速度，多執行緒備份其實也不慢。但恢復速度呢，即使是多執行緒恢復，也很慢。
備份會"汙染"Buffer Pool。業務熱點資料會被備份資料驅逐出Buffer Pool。

2、離線備份 VS 線上備份

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

3、全量備份 VS 增量備份

全量備份，即備份整個範例的全量資料。
增量備份，即只備份上次備份以來，那些發生了"變化"的資料。

通常來說，基於物理備份來實現增量備份較為簡單，以MySQL為例，只需判斷資料頁的LSN是否發生了變化。而對於邏輯備份，就很難實現，如常見的基於某個時間欄位來進行增量備份，但其實，很難保證某個時間段之前的資料不被修改或刪除。

三、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和資料字典的格式發生了變化。

2）mysqlbackup

MySQL企業級備份工具（ MySQL Enterprise Backup ），適用於MySQL企業版。

3）Clone Plugin

MySQL 8.0.17引入的克隆外掛。初衷是為了方便Group Replication新增新的節點。有了Clone Plugin，我們也能很方便的搭建一個從庫，無需藉助其它備份工具。

三者的實現原理基本相同，都是在備份的過程中，拷貝物理檔案和redo log ，最後，再利用InnoDB Crash Recovery，將物理檔案恢復到備份結束時的一致性狀態。

2、邏輯備份

邏輯備份相關的工具有：

1）mysqldump

MySQL安裝包自帶的備份工具，單執行緒備份。

2）mydumper

由Facebook、SkySQL、Oracle和Percona開發人員維護的一個多執行緒備份工具，可實現行級別的並行備份。

3）mysqlpump

MySQL 5.7引入的備份工具，可實現表級別的並行備份。

4）MySQL Shell

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

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

5）SELECT ... INTO OUTFILE

SQL命令，可將表記錄直接匯出到檔案中。

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

從實現原理來看，mysqldump、 mydumper、mysqlpump、 MySQL Shell可歸為一類，本質上都是通過SELECT * FROM TABLE的方式備份資料，只不過在此基礎上，通過全域性讀鎖 + REPEATABLE READ事務隔離級別，實現了資料庫的一致性備份。
SELECT ... INTO OUTFILE 充其量只是一個命令，算不上工具，更不用說資料庫的一致性備份。
從匯出的內容來看，mysqldump、mydumper、mysqlpump 會以INSERT語句的形式儲存備份結果，如：

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

而 MySQL Shell和SELECT ... INTO OUTFILE 是以CSV格式的形式儲存備份結果，如，

1 aaa
2 bbb
3 ccc

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

mysqldump、mysqlpump對應的恢復工具是mysql使用者端，所以是單執行緒恢復。mydumper對應的恢復工具是myloader，支援多執行緒恢復。util.dumpInstance()對應的恢復工具是util.loadDump()，該工具實際呼叫的是LOAD DATA LOCAL INFILE命令，支援多執行緒恢復。SELECT ... INTO OUTFILE對應的恢復命令是LOAD DATA。

四、mysqlbackup VS mysqldump

下面是MySQL官方提供的一組資料，對比了mysqlbackup和mysqldump備份恢復時間。

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

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

藉此，我們也能看到邏輯備份工具相對於物理備份工具在備份、還原速度上的差距。不過可惜的是，這裡沒有測試mydumper。畢竟，針對資料量較大的範例，如果一定要使用邏輯備份，大家一般傾向於使用mydumper，而不是mysqldump。

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

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

驗證整個備份環節的可靠性。包括備份引數是否完備，備份集是否有效，備份媒介是否損壞等。
通過檢查備份的有效性，搭建一套完整的自動化恢復體系。

很多時候，影響資料庫恢復時間的並不是備份集太老，而是手動恢復過程中，因為命令、環境、流程的不熟悉，所帶來的額外耗時。

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

（1）基於備份恢復範例，看範例能否起來。並在此基礎上，進行隨機查詢。

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

（2）在1的基礎上，建立複製。

如果從庫在追主庫的過程中，沒有報錯，大概率意味著主從資料是一致的。當然，也只是大概率，並不是100%。

（3）在2的基礎上，利用pt-table-checksum檢查主從資料的一致性。

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

六、RTO 和 RPO

衡量一個資料中心的容災能力時，有兩個常用的指標：

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

指的是災難發生後，必須在這個時間內恢復資料。在恢復資料的這段時間內，服務是不可用的，所以RTO也是服務可允許的最大不可用時間。如果我們要求服務的最大不可用時間是30分鐘，那麼RTO就是30分鐘。RTO 越小，代表容災系統的恢復能力越強。

RPO：Recovery Point Objective，資料恢復點目標。

指的是災難發生後，資料可以恢復到的時間點。

譬如，我有一個系統，每天0點進行一次全備。當系統出現故障後，會基於上一次的備份來恢復。如果系統在凌晨3點出現故障，我們會丟失3個小時的資料。極端情況下，系統在23:59出現故障，我們會丟失24個小時的資料。這裡的24小時就是這個系統的RPO 。

RPO越小，代表系統越能保證資料的完整性。

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

可以看到，RPO針對的是資料丟失，RTO針對的是服務宕機時間，兩者之間沒有必然的聯絡。

最理想的情況是RTO和RPO都為0，這就意味著當災難發生時，系統會立即恢復，而且資料不會丟失。當然，RTO、RPO越小，需要投入的成本也越高。

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

1、RTO

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

2、RPO

增加備份頻率，縮短備份週期。
搭建Binlog Server備份Binlog。當出現故障時，我們可以基於備份和Binlog做基於時間點的恢復。
新增延遲從庫。

七、總結

從RTO的角度出發，應儘量選擇物理備份，而不是邏輯備份。如果要使用邏輯備份，應儘量選擇多執行緒備份工具和多執行緒恢復工具。

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

到此這篇關於MySQL選擇合適的備份策略和備份工具的文章就介紹到這了,更多相關MySQL備份策略和工具內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！