日韩国产精品99成人不卡在线无毒|狠狠躁夜夜爽一级二级精品|亚洲日日噜噜孕妇中文字幕|日韩久草中文三级片

新聞動態(tài)

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

常見問題 發(fā)布者:ou3377 2021-12-14 09:12 訪問量:338

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

  • 多地部署

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

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

  • 多介質(zhì)部署

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

  • 定期檢查備份的有效性

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

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

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

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

備份的常見分類

物理備份 VS 邏輯備份

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

優(yōu)點:

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

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

  • 無需實例在線。

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

    關(guān)閉實例進行備份,也稱之為 “冷備” 。

缺點:

  • 備份文件大。

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

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

  • 因為是拷貝物理文件,即使文件中存在很多“空洞”(大量DELETE導致),也無法通過恢復(fù)來收縮 。

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

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

優(yōu)點:

  • 可移植性強?;謴?fù)時,對平臺、操作系統(tǒng)、MySQL版本無要求。

  • 靈活。尤其是在恢復(fù)時,可只恢復(fù)一個庫或一張表。

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

  • 備份文件較小。

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

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

缺點:

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

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

  • 備份會"污染"Buffer Pool。

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

離線備份 VS 在線備份

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

在線備份,又可稱之為 "熱備",即實例運行過程中進行的備份。此時,既可進行物理備份,又可進行邏輯備份。

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

全量備份 VS 增量備份

全量備份,即備份整個實例的全量數(shù)據(jù)。

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

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

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

MySQL中的備份工具

物理備份

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

  • 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和數(shù)據(jù)字典的格式發(fā)生了變化。

  • mysqlbackup

    MySQL企業(yè)級備份工具( 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é)點。有了Clone Plugin,我們也能很方便的搭建一個從庫,無需借助其它備份工具。

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

邏輯備份

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

  • mysqldump

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

  • mydumper

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

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

  • mysqlpump

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

  • MySQL Shell

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

    這個工具對備份實例和恢復(fù)實例的版本有要求:備份實例 >= 5.6,恢復(fù)實例 >= 5.7。

  • SELECT ... INTO OUTFILE

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

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

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

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

  3. 從導出的內(nèi)容來看,mysqldump、mydumper、mysqlpump 會以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ù),各個工具對應(yīng)的恢復(fù)工具也不一樣。具體來說,

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

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

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

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

mysqlbackup VS mysqldump

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

圖片


圖片

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

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

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

不過可惜的是,這里沒有測試mydumper。

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

如何檢測備份的有效性

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

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

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

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

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

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

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

    這種檢測方法最簡單。

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

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

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

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

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

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

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

    但因為pt-table-checksum在運行的過程中,會在chunk級別對表加S鎖,對更新頻繁的業(yè)務(wù),還是有一定的影響。

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

方法3,因為要檢查主從數(shù)據(jù)的一致性,耗時相對較久,如果要檢測的備份集很多,反而會影響檢測的效率。

RTO 和 RPO

衡量一個數(shù)據(jù)中心的容災(zāi)能力時,有兩個常用的指標:

  • RTO:Recovery Time Objective,恢復(fù)時間目標。

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

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

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

  • RPO:Recovery Point Objective,數(shù)據(jù)恢復(fù)點目標。

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

    譬如,我有一個系統(tǒng),每天0點進行一次全備。當系統(tǒng)出現(xiàn)故障后,會基于上一次的備份來恢復(fù)。如果系統(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與災(zāi)難在時間軸上的關(guān)系如下圖所示:

圖片


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

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

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

RTO

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

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

  3. 添加延遲從庫。

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

RPO

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

  2. 搭建Binlog Server備份Binlog。當出現(xiàn)故障時,我們可以基于備份和Binlog做基于時間點的恢復(fù)。

  3. 添加延遲從庫。

總結(jié)

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

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

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

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

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

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



關(guān)鍵字: MySQL MySQ備份工具

文章連接: http://www.hsjyfc.com.cn/cjwt/816.html

版權(quán)聲明:文章由 晨展科技 整理收集,來源于互聯(lián)網(wǎng)或者用戶投稿,如有侵權(quán),請聯(lián)系我們,我們會立即刪除。如轉(zhuǎn)載請保留