咨詢(xún)電話(huà)
微信掃一掃
新聞動(dòng)態(tài)
MySQL中如何選擇合適的備份策略和備份工具
常見(jiàn)問(wèn)題 發(fā)布者:ou3377 2021-12-14 09:12 訪(fǎng)問(wèn)量:127
數據庫備份的重要性毋庸置疑,可以說(shuō),它是數據安全的最后一道防線(xiàn)。鑒于此,對于備份,我們通常會(huì )做以下要求:
多地部署
對于核心數據庫,我們通常有兩地三中心的部署要求。對于備份來(lái)說(shuō),也是如此。
一個(gè)備份應該有多個(gè)副本,每個(gè)副本存儲在不同區域。
多介質(zhì)部署
一個(gè)備份的多個(gè)副本應存儲在不同介質(zhì)上,如磁盤(pán)和磁帶,防止單一介質(zhì)失效。
定期檢查備份的有效性
備份只是在做正確的事情,有沒(méi)有把事情做對,還得依靠備份的有效性檢查。
前兩項,在條件允許的情況下,建議做。第三項必須做。
接下來(lái),我們聊聊備份的相關(guān)話(huà)題,主要包括以下五方面的內容:
物理備份,顧名思義,就是備份物理文件。其優(yōu)缺點(diǎn)如下:
優(yōu)點(diǎn):
備份、恢復速度快。
尤其是恢復速度,直接關(guān)系著(zhù)數據庫服務(wù)的RTO。
無(wú)需實(shí)例在線(xiàn)。
在實(shí)例關(guān)閉的情況下,可直接拷貝文件,不用擔心備份的一致性。
關(guān)閉實(shí)例進(jìn)行備份,也稱(chēng)之為 “冷備” 。
缺點(diǎn):
備份文件大。
恢復時(shí),對平臺、操作系統、MySQL版本有要求,必須一致或兼容。
只能在本地發(fā)起備份。
因為是拷貝物理文件,即使文件中存在很多“空洞”(大量DELETE導致),也無(wú)法通過(guò)恢復來(lái)收縮 。
對表的存儲引擎有要求,無(wú)法備份MEMORY表。
邏輯備份,備份表的邏輯記錄。其優(yōu)缺點(diǎn)如下:
優(yōu)點(diǎn):
可移植性強?;謴蜁r(shí),對平臺、操作系統、MySQL版本無(wú)要求。
靈活。尤其是在恢復時(shí),可只恢復一個(gè)庫或一張表。
對表的存儲引擎沒(méi)有要求,任何類(lèi)型的表都可備份。
備份文件較小。
可遠程發(fā)起備份。
恢復后,能有效收縮空間。
缺點(diǎn):
備份、恢復速度慢。
實(shí)際上,單論備份速度,多線(xiàn)程備份其實(shí)也不慢。但恢復速度呢,即使是多線(xiàn)程恢復,也很慢。
備份會(huì )"污染"Buffer Pool。
業(yè)務(wù)熱點(diǎn)數據會(huì )被備份數據驅逐出Buffer Pool 。
離線(xiàn)備份,又可稱(chēng)之為 "冷備",即實(shí)例關(guān)閉的情況下進(jìn)行的備份。此時(shí),只能進(jìn)行物理備份,即全量拷貝物理文件。
在線(xiàn)備份,又可稱(chēng)之為 "熱備",即實(shí)例運行過(guò)程中進(jìn)行的備份。此時(shí),既可進(jìn)行物理備份,又可進(jìn)行邏輯備份。
因對業(yè)務(wù)侵入較小,線(xiàn)上一般使用在線(xiàn)備份。
全量備份,即備份整個(gè)實(shí)例的全量數據。
增量備份,即只備份上次備份以來(lái),那些發(fā)生了"變化"的數據。
通常來(lái)說(shuō),基于物理備份來(lái)實(shí)現增量備份較為簡(jiǎn)單,以MySQL為例,只需判斷數據頁(yè)的LSN是否發(fā)生了變化。
而對于邏輯備份,就很難實(shí)現,如常見(jiàn)的基于某個(gè)時(shí)間字段來(lái)進(jìn)行增量備份,但其實(shí),很難保證某個(gè)時(shí)間段之前的數據不被修改或刪除。
物理備份相關(guān)的工具有:
XtraBackup
Percona公司開(kāi)源的備份工具,適用于MySQL、MariaDB、Percona Server。
https://www.percona.com/software/mysql-database/percona-xtrabackup
XtraBackup目前維護的大版本有兩個(gè):
1. XtraBackup 2.4,適用于MySQL 5.6和5.7。
2. XtraBackup 8.0。適用于 MySQL 8.0。
之所以要維護兩個(gè)版本,是因為MySQL 8.0中的redo log和數據字典的格式發(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添加新的節點(diǎn)。有了Clone Plugin,我們也能很方便的搭建一個(gè)從庫,無(wú)需借助其它備份工具。
三者的實(shí)現原理基本相同,都是在備份的過(guò)程中,拷貝物理文件和redo log ,最后,再利用InnoDB Crash Recovery,將物理文件恢復到備份結束時(shí)的一致性狀態(tài)。
邏輯備份相關(guān)的工具有:
mysqldump
MySQL安裝包自帶的備份工具,單線(xiàn)程備份。
mydumper
由Facebook、SkySQL、Oracle和Percona開(kāi)發(fā)人員維護的一個(gè)多線(xiàn)程備份工具,可實(shí)現行級別的并行備份。
https://github.com/maxbube/mydumper
mysqlpump
MySQL 5.7引入的備份工具,可實(shí)現表級別的并行備份。
MySQL Shell
MySQL Shell 8.0.21引入了一個(gè)工具-util.dumpInstance(),可實(shí)現行級別的并行備份。
這個(gè)工具對備份實(shí)例和恢復實(shí)例的版本有要求:備份實(shí)例 >= 5.6,恢復實(shí)例 >= 5.7。
SELECT ... INTO OUTFILE
SQL命令,可將表記錄直接導出到文件中。
下面說(shuō)說(shuō)這幾個(gè)工具的異同點(diǎn):
從實(shí)現原理來(lái)看,mysqldump、 mydumper、mysqlpump、 MySQL Shell可歸為一類(lèi),本質(zhì)上都是通過(guò)SELECT * FROM TABLE的方式備份數據,只不過(guò)在此基礎上,通過(guò)全局讀鎖 + REPEATABLE READ事務(wù)隔離級別,實(shí)現了數據庫的一致性備份。
SELECT ... INTO OUTFILE 充其量只是一個(gè)命令,算不上工具,更不用說(shuō)數據庫的一致性備份。
從導出的內容來(lái)看,mysqldump、mydumper、mysqlpump 會(huì )以INSERT語(yǔ)句的形式保存備份結果,如,
INSERT INTO `t1` VALUES (1,'aaa'),(2,'bbb'),(3,'ccc');
而 MySQL Shell和SELECT ... INTO OUTFILE 是以CSV格式的形式保存備份結果,如,
1 aaa
2 bbb
3 ccc
在恢復,各個(gè)工具對應的恢復工具也不一樣。具體來(lái)說(shuō),
mysqldump、mysqlpump對應的恢復工具是mysql客戶(hù)端,所以是單線(xiàn)程恢復。
mydumper對應的恢復工具是myloader,支持多線(xiàn)程恢復。
util.dumpInstance()對應的恢復工具是util.loadDump(),該工具實(shí)際調用的是LOAD DATA LOCAL INFILE命令,支持多線(xiàn)程恢復。
SELECT ... INTO OUTFILE對應的恢復命令是LOAD DATA。
下面是MySQL官方提供的一組數據,對比了mysqlbackup和mysqldump備份恢復時(shí)間。
第一張圖比較的是備份時(shí)間,mysqldump是mysqlbackup的49倍。
第二張圖比較的是恢復時(shí)間,mysqldump是mysqlbackup的80倍。
借此,我們也能看到邏輯備份工具相對于物理備份工具在備份、還原速度上的差距。
不過(guò)可惜的是,這里沒(méi)有測試mydumper。
畢竟,針對數據量較大的實(shí)例,如果一定要使用邏輯備份,大家一般傾向于使用mydumper,而不是mysqldump。
為什么要檢測備份的有效性,原因主要有兩個(gè):
驗證整個(gè)備份環(huán)節的可靠性。
包括備份參數是否完備,備份集是否有效,備份介質(zhì)是否損壞等。
通過(guò)檢查備份的有效性,搭建一套完整的自動(dòng)化恢復體系。
很多時(shí)候,影響數據庫恢復時(shí)間的并不是備份集太老,而是手動(dòng)恢復過(guò)程中,因為命令、環(huán)境、流程的不熟悉,所帶來(lái)的額外耗時(shí)。
如何檢測備份的有效性,常用的方法有三個(gè):
基于備份恢復實(shí)例,看實(shí)例能否起來(lái)。并在此基礎上,進(jìn)行隨機查詢(xún)。
這種檢測方法最簡(jiǎn)單。
一般來(lái)說(shuō),實(shí)例能起來(lái),且隨機查詢(xún)也沒(méi)問(wèn)題,就意味著(zhù)這個(gè)備份集是可用的。
但備份集可用,并不意味著(zhù)這個(gè)備份集能滿(mǎn)足我們的需求,譬如常見(jiàn)的,搭建從庫。
而且一些常見(jiàn)的問(wèn)題,如備份中斷、參數沒(méi)指定準確,也無(wú)法通過(guò)這種方式檢測出來(lái)。
在1的基礎上,建立復制。
如果從庫在追主庫的過(guò)程中,沒(méi)有報錯,大概率意味著(zhù)主從數據是一致的。當然,也只是大概率,并不是100%。
在2的基礎上,利用pt-table-checksum檢查主從數據的一致性。
如果檢查結果沒(méi)問(wèn)題,則意味著(zhù)主從數據是一致的,也就間接證明了備份的有效性。
但因為pt-table-checksum在運行的過(guò)程中,會(huì )在chunk級別對表加S鎖,對更新頻繁的業(yè)務(wù),還是有一定的影響。
一般來(lái)說(shuō),線(xiàn)上使用方法2足矣。
方法3,因為要檢查主從數據的一致性,耗時(shí)相對較久,如果要檢測的備份集很多,反而會(huì )影響檢測的效率。
衡量一個(gè)數據中心的容災能力時(shí),有兩個(gè)常用的指標:
RTO:Recovery Time Objective,恢復時(shí)間目標。
指的是災難發(fā)生后,必須在這個(gè)時(shí)間內恢復數據。
在恢復數據的這段時(shí)間內,服務(wù)是不可用的,所以RTO也是服務(wù)可允許的最大不可用時(shí)間。如果我們要求服務(wù)的最大不可用時(shí)間是30分鐘,那么RTO就是30分鐘。
RTO 越小,代表容災系統的恢復能力越強。
RPO:Recovery Point Objective,數據恢復點(diǎn)目標。
指的是災難發(fā)生后,數據可以恢復到的時(shí)間點(diǎn)。
譬如,我有一個(gè)系統,每天0點(diǎn)進(jìn)行一次全備。當系統出現故障后,會(huì )基于上一次的備份來(lái)恢復。如果系統在凌晨3點(diǎn)出現故障,我們會(huì )丟失3個(gè)小時(shí)的數據。極端情況下,系統在23:59出現故障,我們會(huì )丟失24個(gè)小時(shí)的數據。這里的24小時(shí)就是這個(gè)系統的RPO 。
RPO越小,代表系統越能保證數據的完整性。
RTO、RPO與災難在時(shí)間軸上的關(guān)系如下圖所示:
可以看到,RPO針對的是數據丟失,RTO針對的是服務(wù)宕機時(shí)間,兩者之間沒(méi)有必然的聯(lián)系。
最理想的情況是RTO和RPO都為0,這就意味著(zhù)當災難發(fā)生時(shí),系統會(huì )立即恢復,而且數據不會(huì )丟失。當然,RTO、RPO越小,需要投入的成本也越高。
具體到MySQL中,為了降低RTO和RPO,我們可以從以下幾個(gè)方面著(zhù)手:
RTO
增加備份頻率,縮短備份周期。
選擇物理備份,而不是邏輯備份。
添加延遲從庫。
恢復流程的自動(dòng)化。
RPO
增加備份頻率,縮短備份周期。
搭建Binlog Server備份Binlog。當出現故障時(shí),我們可以基于備份和Binlog做基于時(shí)間點(diǎn)的恢復。
添加延遲從庫。
從RTO的角度出發(fā),應盡量選擇物理備份,而不是邏輯備份。如果要使用邏輯備份,應盡量選擇多線(xiàn)程備份工具和多線(xiàn)程恢復工具。
從RPO的角度出發(fā),應盡量增加備份頻率,縮短備份周期。
但 every coin has two sides,使用物理備份或者增加備份頻率,無(wú)疑會(huì )增加存儲成本。
所以,在確定備份策略和選擇備份工具時(shí),應從業(yè)務(wù)的RTO和RPO出發(fā),結合存儲成本綜合考慮。
大多數公司會(huì )采取一個(gè)統一的備份策略,如一天一個(gè)全備。雖然災難情況很少出現,開(kāi)發(fā)和DBA童鞋也應充分理解到這里面的風(fēng)險,并制定相應的預案及業(yè)務(wù)兜底方案。
另外,對于線(xiàn)上核心業(yè)務(wù),如果只有備份,還是很難有效降低數據庫服務(wù)的RTO和RPO,建議部署延遲從庫。
【推薦閱讀】
文章連接: http://www.gostscript.com/cjwt/816.html
版權聲明:文章由 晨展科技 整理收集,來(lái)源于互聯(lián)網(wǎng)或者用戶(hù)投稿,如有侵權,請聯(lián)系我們,我們會(huì )立即刪除。如轉載請保留
晨展解決方案
晨展新聞