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

iVictor發表於2021-10-16
MySql

​資料庫備份的重要性毋庸置疑，可以說，它是資料安全的最後一道防線。鑑於此，對於備份，我們通常會做以下要求：

  • 多地部署

    對於核心資料庫，我們通常有兩地三中心的部署要求。對於備份來說，也是如此。

    一個備份應該有多個副本，每個副本儲存在不同區域。

  • 多介質部署

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

  • 定期檢查備份的有效性

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

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

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

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

備份的常見分類

物理備份 VS 邏輯備份

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

優點：

  • 備份、恢復速度快。

    尤其是恢復速度，直接關係著資料庫服務的RTO。

  • 無需例項線上。

    在例項關閉的情況下，可直接拷貝檔案，不用擔心備份的一致性。

    關閉例項進行備份，也稱之為 “冷備” 。

缺點：

  • 備份檔案大。

  • 恢復時，對平臺、作業系統、MySQL版本有要求，必須一致或相容。

  • 只能在本地發起備份。

  • 因為是拷貝物理檔案，即使檔案中存在很多“空洞”（大量DELETE導致），也無法通過恢復來收縮 。

  • 對錶的儲存引擎有要求，無法備份MEMORY表。

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

優點：

  • 可移植性強。恢復時，對平臺、作業系統、MySQL版本無要求。

  • 靈活。尤其是在恢復時，可只恢復一個庫或一張表。

  • 對錶的儲存引擎沒有要求，任何型別的表都可備份。

  • 備份檔案較小。

  • 可遠端發起備份。

  • 恢復後，能有效收縮空間。

缺點：

  • 備份、恢復速度慢。

    實際上，單論備份速度，多執行緒備份其實也不慢。但恢復速度呢，即使是多執行緒恢復，也很慢。

  • 備份會"汙染"Buffer Pool。

    業務熱點資料會被備份資料驅逐出Buffer Pool 。

離線備份 VS 線上備份

離線備份，又可稱之為 "冷備"，即例項關閉的情況下進行的備份。此時，只能進行物理備份，即全量拷貝物理檔案。

線上備份，又可稱之為 "熱備"，即例項執行過程中進行的備份。此時，既可進行物理備份，又可進行邏輯備份。

因對業務侵入較小，線上一般使用線上備份。

全量備份 VS 增量備份

全量備份，即備份整個例項的全量資料。

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

通常來說，基於物理備份來實現增量備份較為簡單，以MySQL為例，只需判斷資料頁的LSN是否發生了變化。

而對於邏輯備份，就很難實現，如常見的基於某個時間欄位來進行增量備份，但其實，很難保證某個時間段之前的資料不被修改或刪除。

MySQL中的備份工具

物理備份

物理備份相關的工具有：

  • XtraBackup

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

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

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

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

    2. XtraBackup 8.0。適用於 MySQL 8.0。

    之所以要維護兩個版本，是因為MySQL 8.0中的redo log和資料字典的格式發生了變化。

  • mysqlbackup

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

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

  • Clone Plugin

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

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

邏輯備份

邏輯備份相關的工具有：

  • mysqldump

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

  • mydumper

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

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

  • mysqlpump

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

  • MySQL Shell

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

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

  • SELECT ... INTO OUTFILE

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

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

  1. 從實現原理來看，mysqldump、 mydumper、mysqlpump、 MySQL Shell可歸為一類，本質上都是通過SELECT * FROM TABLE的方式備份資料，只不過在此基礎上，通過全域性讀鎖 + REPEATABLE READ事務隔離級別，實現了資料庫的一致性備份。

  2. SELECT ... INTO OUTFILE 充其量只是一個命令，算不上工具，更不用說資料庫的一致性備份。

  3. 從匯出的內容來看，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

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

    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. 基於備份恢復例項，看例項能否起來。並在此基礎上，進行隨機查詢。

    這種檢測方法最簡單。

    一般來說，例項能起來，且隨機查詢也沒問題，就意味著這個備份集是可用的。

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

    而且一些常見的問題，如備份中斷、引數沒指定準確，也無法通過這種方式檢測出來。

  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，我們可以從以下幾個方面著手：

RTO

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

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

  3. 新增延遲從庫。

  4. 恢復流程的自動化。

RPO

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

  2. 搭建Binlog Server備份Binlog。當出現故障時，我們可以基於備份和Binlog做基於時間點的恢復。

  3. 新增延遲從庫。

總結

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

從RPO的角度出發，應儘量增加備份頻率，縮短備份週期。

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

所以，在確定備份策略和選擇備份工具時，應從業務的RTO和RPO出發，結合儲存成本綜合考慮。

大多數公司會採取一個統一的備份策略，如一天一個全備。雖然災難情況很少出現，開發和DBA童鞋也應充分理解到這裡面的風險，並制定相應的預案及業務兜底方案。

另外，對於線上核心業務，如果只有備份，還是很難有效降低資料庫服務的RTO和RPO，建議部署延遲從庫。

參考

[1] 關於RTO，你理解對了嗎？

[2] 恢復時間目標 (RTO) 和恢復點目標 (RPO) 

[3] MySQL Enterprise Backup https://www.mysql.com/cn/products/enterprise/backup.html

相關文章