一、概述

vivo互聯(lián)網(wǎng)領(lǐng)域擁有的數(shù)據(jù)庫(kù)組件分別為 MySQL、MongoDB、TiDB 等，其中MySQL集群占比絕大部分，  MongoDB 集群占比小部分， TiDB 集群占比更小。目前備份存儲(chǔ)14天，磁盤(pán)總量為1PB。為了介紹方便，本文把改造前的數(shù)據(jù)庫(kù)備份恢復(fù)系統(tǒng)稱為舊備份恢復(fù)系統(tǒng)，改造后的數(shù)據(jù)庫(kù)備份恢復(fù)系統(tǒng)稱為新備份恢復(fù)系統(tǒng)。我們將從舊的架構(gòu)系統(tǒng)開(kāi)始，發(fā)現(xiàn)其不足，慢慢的優(yōu)化形成新的系統(tǒng)架構(gòu)。

二、舊備份恢復(fù)系統(tǒng)

舊備份恢復(fù)系統(tǒng)架構(gòu)圖

舊備份恢復(fù)系統(tǒng)是基于Python 語(yǔ)言開(kāi)發(fā)的，使用分布式文件系統(tǒng)GlusterFS，Python作為開(kāi)發(fā)語(yǔ)言，使用任務(wù)調(diào)度模塊Celery下發(fā)備份和恢復(fù)任務(wù)。或許由于之前開(kāi)發(fā)時(shí)間緊迫，在服務(wù)可用性和Redis組件高可用性上，并未做過(guò)多的工作。若出現(xiàn)物理機(jī)宕機(jī)或網(wǎng)絡(luò)等問(wèn)題，將直接影響備份系統(tǒng)的穩(wěn)定性。

2.1 備份模塊

備份模塊是舊備份恢復(fù)系統(tǒng)的一個(gè)主要功能服務(wù)，主要用于MySQL、TiDB、MongoDB 組件的備份調(diào)度、備份等任務(wù)，來(lái)完成每日的數(shù)據(jù)庫(kù)備份。舊備份恢復(fù)系統(tǒng)主要使用的是邏輯備份，在僅有5臺(tái)物理機(jī)上負(fù)責(zé)備份任務(wù)的發(fā)起和執(zhí)行，由于互聯(lián)網(wǎng)的體量大，數(shù)據(jù)庫(kù)全備一次需要2天的時(shí)間，因此備份的成功率是按照2天統(tǒng)計(jì)。由于文件系統(tǒng)的高負(fù)載，以及備份中鎖等原因也會(huì)出現(xiàn)備份調(diào)度失敗的情況，導(dǎo)致整個(gè)物理機(jī)上的實(shí)例不能再次發(fā)起備份，需要手工維護(hù)才能繼續(xù)備份，系統(tǒng)維護(hù)上也非常麻煩。

2.2 組件備份介紹

MySQL和TiDB的備份

【備份工具】：Mydumper + Xtrabackup(MySQL)

【備份方式】：邏輯備份 + 物理機(jī)備份

邏輯備份 Mydumper 工具

Mydumper 是一款社區(qū)開(kāi)源的邏輯備份工具。該工具主要由 C 語(yǔ)言編寫(xiě)，目前由 MySQL 、Facebook 等公司人員開(kāi)發(fā)維護(hù)。

參考官方介紹，Mydumper 主要有以下幾點(diǎn)特性：

• 支持多線程導(dǎo)出數(shù)據(jù)，速度更快。
• 支持一致性備份。
• 支持將導(dǎo)出文件壓縮，節(jié)約空間。
• 支持多線程恢復(fù)。
• 支持以守護(hù)進(jìn)程模式工作，定時(shí)快照和連續(xù)二進(jìn)制日志。
• 支持按照指定大小將備份文件切割。
• 數(shù)據(jù)與建表語(yǔ)句分離。

Mydumper的主要工作步驟：

1. 主線程 flush tables with read lock, 施加全局只讀鎖，以阻止dml語(yǔ)句寫(xiě)入，保證數(shù)據(jù)的一致性。
2. 讀取當(dāng)前時(shí)間點(diǎn)的二進(jìn)制日志文件名和日志寫(xiě)入的位置并記錄在metadata文件中，以供恢復(fù)使用。
3. start transaction with consistent snapshot; 開(kāi)啟讀一致事務(wù)。
4. 啟用n個(gè)（線程數(shù)可以指定，默認(rèn)是4）dump線程導(dǎo)出表和表結(jié)構(gòu)。
5. 備份非事務(wù)類(lèi)型的表。
6. 主線程 unlock tables，備份完成非事務(wù)類(lèi)型的表之后，釋放全局只讀鎖。
7. 基于事務(wù)dump innodb tables。
8. 事務(wù)結(jié)束。

基于Mydumper 以上的特性，PingCAP公司針對(duì) TiDB 的特性進(jìn)行了優(yōu)化，Mydumper 包含在 tidb-enterprise-tools 安裝包中。對(duì)于 TiDB 可以設(shè)置 tidb_snapshot 的值指定備份數(shù)據(jù)的時(shí)間點(diǎn)，從而保證備份的一致性，而不是通過(guò) FLUSH TABLES WITH READ LOCK 來(lái)保證備份一致性。使用 TiDB 的隱藏列 _tidb_rowid 優(yōu)化了單表內(nèi)數(shù)據(jù)的并發(fā)導(dǎo)出性能。TiDB 官方早起提供了Mydumper備份工具，后期提供了BR 物理機(jī)備份工具，然而物理機(jī)備份受限制于文件系統(tǒng)，在GlusterFS 文件系統(tǒng)下，只能使用Mydumper 做邏輯備份。

Mydumper 備份屬于邏輯備份，需要讀全表，因此備份效率會(huì)低很多。同一個(gè)數(shù)據(jù)庫(kù)，在文件系統(tǒng)不變的情況下，邏輯備份和物理備份的對(duì)比。

從該統(tǒng)計(jì)可以看出，邏輯備份時(shí)間很不穩(wěn)定，Mydumper 備份最短一次是6.5個(gè)小時(shí)，最長(zhǎng)在23小時(shí)，而物理機(jī)備份時(shí)間基本維持在7個(gè)小時(shí)左右。

物理機(jī)備份Xtrabackup工具

Xtrabackup是Percona團(tuán)隊(duì)開(kāi)發(fā)的用于MySQL數(shù)據(jù)庫(kù)物理熱備份的開(kāi)源備份工具，具有備份速度快、支持備份數(shù)據(jù)壓縮、自動(dòng)校驗(yàn)備份數(shù)據(jù)、支持流式輸出、備份過(guò)程中幾乎不影響業(yè)務(wù)等特點(diǎn)，是目前各個(gè)云廠商普遍使用的MySQL備份工具。

由于物理機(jī)備份未使用壓縮和打包，備份的文件受限于表的大小，在備份特別大的表時(shí)，總會(huì)出現(xiàn)文件系統(tǒng)分布不均勻的情況，大部分磁盤(pán)在80%的時(shí)候，某些磁盤(pán)的使用容量卻超過(guò)95%，需要經(jīng)常登錄文件系統(tǒng)刪除備份文件來(lái)消除告警。另外物理備份配置比例較小，備份占比不高。后續(xù)雖然經(jīng)過(guò)一些了優(yōu)化（增加打包和文件分拆功能），解決了磁盤(pán)分布不均的問(wèn)題。但備份成功率提升不明顯。

MongoDB 備份

【備份工具】：mongodbdump

【備份方式】：邏輯備份

【備份時(shí)間】：全天時(shí)間段

mongodbdump 是MongoDB 官方提供的備份程序，對(duì)于小于100G以內(nèi)的備份還能輕松應(yīng)付，但對(duì)于大于100G的實(shí)例雖然也能備份，不過(guò)備份時(shí)間會(huì)比較長(zhǎng)。vivo目前有幾十個(gè)大于1T的實(shí)例，備份難度可想而知，備份成功率很低。有些MongoDB 實(shí)例因?yàn)樘?，?dǎo)致從未成功過(guò)。2天的備份成功率基本在20%左右，哪怕統(tǒng)計(jì)一周的成功率也無(wú)法達(dá)到40%，大于1T的MongoDB 實(shí)例，因?yàn)槲募到y(tǒng)過(guò)慢，總是出現(xiàn)備份一半就出現(xiàn)失敗，雖經(jīng)過(guò)多次優(yōu)化，哪怕是把備份盤(pán)放置本地盤(pán)，再拷貝至文件系統(tǒng)，雖然備份成功率有所提高，但成功率依舊很差，而且還需要經(jīng)常手工維護(hù)。

2.3 恢復(fù)模塊

恢復(fù)模塊也是基于Python開(kāi)發(fā)，由Celery 模塊調(diào)度恢復(fù)策略，根據(jù)已配置的數(shù)據(jù)庫(kù)備份方式，選擇相應(yīng)的邏輯和物理機(jī)恢復(fù)。

邏輯恢復(fù)是直接使用備份文件對(duì)目標(biāo)庫(kù)進(jìn)行恢復(fù)，不過(guò)邏輯恢復(fù)很慢，之前做過(guò)一次上T的數(shù)據(jù)庫(kù)恢復(fù)，竟然恢復(fù)了1天左右的時(shí)間。不過(guò)邏輯備份也是有好處的，在恢復(fù)單個(gè)表時(shí)，可以直接把該表的文件系統(tǒng)拷貝出來(lái)，直接使用myloader程序直接恢復(fù)，可以非?？焖俚幕謴?fù)單表，這比物理機(jī)恢復(fù)單個(gè)表要快很多。不過(guò)這里的恢復(fù)需要手工操作，代碼并未實(shí)現(xiàn)該項(xiàng)功能。。

物理機(jī)恢復(fù)是直接使用文件系統(tǒng)掛載的方式，直接把文件系統(tǒng)掛載至目標(biāo)機(jī)器，把備份的文件拷貝紙目標(biāo)機(jī)器來(lái)恢復(fù)數(shù)據(jù)，功能相對(duì)簡(jiǎn)單一些，由于是直接拷貝文件，恢復(fù)速度相對(duì)會(huì)快一些。

恢復(fù)模塊僅用于增加從庫(kù)實(shí)例和延遲從庫(kù)，未做到任一時(shí)間點(diǎn)的恢復(fù)，功能相對(duì)單一。

2.4 文件系統(tǒng)

GlusterFS系統(tǒng)是一個(gè)可擴(kuò)展的網(wǎng)絡(luò)文件系統(tǒng)，相比其他分布式文件系統(tǒng)，GlusterFS具有高擴(kuò)展性、高可用性、高性能、可橫向擴(kuò)展等特點(diǎn)，并且其沒(méi)有元數(shù)據(jù)服務(wù)器的設(shè)計(jì)，讓整個(gè)服務(wù)沒(méi)有單點(diǎn)故障的隱患。當(dāng)客戶端訪問(wèn)GlusterFS存儲(chǔ)時(shí)，首先程序通過(guò)訪問(wèn)掛載點(diǎn)的形式讀寫(xiě)數(shù)據(jù)，對(duì)于用戶和程序而言，集群文件系統(tǒng)是透明的，用戶和程序根本感覺(jué)不到文件系統(tǒng)是本地還是在遠(yuǎn)程服務(wù)器上。讀寫(xiě)操作將會(huì)被交給VFS(Virtual File System)來(lái)處理，VFS會(huì)將請(qǐng)求交給FUSE內(nèi)核模塊，而FUSE又會(huì)通過(guò)設(shè)備/dev/fuse將數(shù)據(jù)交給GlusterFS Client。最后經(jīng)過(guò)GlusterFS Client的計(jì)算，并最終經(jīng)過(guò)網(wǎng)絡(luò)將請(qǐng)求或數(shù)據(jù)發(fā)送到GlusterFS Server上。

vivo的備份模塊使用的GlusterFS 文件系統(tǒng)，分別在兩個(gè)區(qū)域的機(jī)房中。其中A機(jī)房是用于數(shù)據(jù)庫(kù)備份和恢復(fù)，B機(jī)房主要用于異地災(zāi)備，增加備份文件的安全性。

A機(jī)房的文件系統(tǒng)主要掛載至備份恢復(fù)的主控機(jī)上，并且A機(jī)房文件系統(tǒng)也會(huì)掛載到需要物理備份的物理機(jī)上。數(shù)據(jù)庫(kù)的物理機(jī)任何DBA人員均可登錄，只要登錄該機(jī)器上，便可以操作任一備份文件，這對(duì)于備份文件是十分危險(xiǎn)的；由于A機(jī)房是單機(jī)房，存在單機(jī)房故障的可能，基于以上兩點(diǎn)，B機(jī)房就應(yīng)運(yùn)而生了。

B機(jī)房的文件系統(tǒng)只掛載至備份恢復(fù)機(jī)器的主控機(jī)上，并且把A機(jī)房的備份文件拷貝至B機(jī)房，同時(shí)管控備份恢復(fù)的主控機(jī)權(quán)限，便可以確保備份文件系統(tǒng)的安全性?；诖?，備份恢復(fù)主控機(jī)及B機(jī)房物理機(jī)權(quán)限只有2個(gè)人有權(quán)限訪問(wèn)，從而確保備份文件的安全性。

2.5 Copy 模塊

Copy 模塊主要用于備份文件的拷貝，讓備份文件保留2份副本，防止因A機(jī)房宕機(jī)，誤刪等情況下，導(dǎo)致備份文件的缺失。

A機(jī)房的文件系統(tǒng)用于數(shù)據(jù)庫(kù)直接備份，B機(jī)房的文件系統(tǒng)中的數(shù)據(jù)，是由A機(jī)房通過(guò)Copy程序拷貝過(guò)來(lái)，在B機(jī)房保留一份副本。由于A機(jī)房承接備份和恢復(fù)兩大功能，而且還要應(yīng)用于拷貝文件至B機(jī)房，還要定時(shí)刪除過(guò)期的備份文件，由此可知A機(jī)房的文件系統(tǒng)壓力將有多大，這也是直接導(dǎo)致Copy程序效率將有多差，最終結(jié)果是B機(jī)房的文件要遠(yuǎn)遠(yuǎn)落后A機(jī)房，導(dǎo)致B機(jī)房異地備份名存實(shí)亡，Copy模塊也變得形同虛設(shè)。

2.6 舊備份恢復(fù)系統(tǒng)存在問(wèn)題

1. 效率不足

MySQL 兩天才能完成一次全備份，而且恢復(fù)實(shí)例時(shí)間也比較長(zhǎng)，不能滿足日?；謴?fù)實(shí)例的時(shí)間要求。

MongoDB 大容量數(shù)據(jù)庫(kù)比較多，而且邏輯備份已經(jīng)無(wú)法應(yīng)付現(xiàn)在的場(chǎng)景，超過(guò)50%以上的MongoDB集群已無(wú)法成功備份。

2. 舊功能不足

舊備份恢復(fù)系統(tǒng)目前只有 備份模塊、恢復(fù)模塊、Copy模塊，功能單一，已經(jīng)不能滿足互聯(lián)網(wǎng)領(lǐng)域的快速發(fā)展。

備份系統(tǒng)是Python代碼完成的，最初開(kāi)發(fā)未考慮高可用，邏輯復(fù)雜，維護(hù)困難。

3. 文件系統(tǒng)方面

① 文件系統(tǒng)權(quán)限控制較弱，不能達(dá)到安全要求

• A機(jī)房文件系統(tǒng)會(huì)有多處掛載，導(dǎo)致備份文件安全無(wú)法得到保障

② 文件系統(tǒng)壓力較大，文件系統(tǒng)已經(jīng)不堪重負(fù)

③ 異地災(zāi)備形同虛設(shè)

• 受文件系統(tǒng)讀寫(xiě)的限制，異地災(zāi)備的文件系統(tǒng)存儲(chǔ)的都是幾天之前的備份文件

三、新備份恢復(fù)系統(tǒng)

基于Python開(kāi)發(fā)的舊備份恢復(fù)系統(tǒng)存在許多缺點(diǎn)，最后引入Java 開(kāi)發(fā)人員和對(duì)象存儲(chǔ)，對(duì)備份系統(tǒng)進(jìn)行全方位的改造，經(jīng)過(guò)一系列改進(jìn)，互聯(lián)網(wǎng)領(lǐng)域目前的備份系統(tǒng)架構(gòu)圖如下：

3.1 新備份恢復(fù)系統(tǒng)效率的提升

新備份恢復(fù)系統(tǒng)改善

Java 語(yǔ)言 + Redis cluster 

Redis 系統(tǒng)終于從主從版本改成Redis cluster 集群版本，Redis可用性得到很大的提高。

1. MySQL備份效率提升

【備份工具】：Mydumper + Xtrabackup

【備份方式】：邏輯備份 + 物理機(jī)備份

【備份策略】：備份不再受限于文件系統(tǒng)的影響，為了快速備份、對(duì)于數(shù)據(jù)庫(kù)data目錄存儲(chǔ)大于20G使用物理備份，小于20G的使用邏輯備份。

【備份時(shí)間】：00-10 之間就能完成當(dāng)天的備份，大大的提高了備份效率。

在互聯(lián)網(wǎng)領(lǐng)域數(shù)據(jù)庫(kù)新的備份系統(tǒng)中，MySQL備份恢復(fù)采用的是邏輯備份與恢復(fù)、物理備份與恢復(fù)并存的模式，根據(jù)集群大小區(qū)分邏輯備份與物理備份。邏輯備份與恢復(fù)采用的工具是Mydumper 和 myloader，物理備份采用的是對(duì)Xtrabackup進(jìn)行包裝過(guò)的工具Xtrabackup_agent（主要是對(duì)備份文件上傳至對(duì)象存儲(chǔ)以及恢復(fù)從對(duì)象存儲(chǔ)下載備份文件進(jìn)行包裝以及流式備份的包裝）。

物理機(jī)備份在最后階段會(huì)獲取整個(gè)數(shù)據(jù)庫(kù)的元數(shù)據(jù)鎖，在日常的備份過(guò)程中經(jīng)常會(huì)出現(xiàn)waiting_for的告警，經(jīng)分析得知，大數(shù)據(jù)在對(duì)特定的表采集時(shí)，未釋放元數(shù)據(jù)鎖，而新的采集又要獲取被備份系統(tǒng)已經(jīng)持有的元數(shù)據(jù)鎖，因此夜間的備份會(huì)告警出來(lái)，影響值班人員的休息，而且由于大數(shù)據(jù)采集SQL因?yàn)榉浅Ｂ?jīng)常與備份產(chǎn)生沖突，為了避免該沖突，備份增加 --ftwrl-wait-timeout參數(shù)，為了減少waiting_for的告警，目前的設(shè)置并不能避免waiting_for的告警，還需要優(yōu)化慢SQL語(yǔ)句，才能做到治標(biāo)治本。

--ftwrl-wait-timeout

指明執(zhí)行flush tables with read lock前的等待時(shí)間，0表示不等待直接執(zhí)行鎖表命令，單位是s，若超過(guò)此參數(shù)設(shè)置的時(shí)間后還存在長(zhǎng)時(shí)間執(zhí)行的查詢，則Xtrabackup終止運(yùn)行。

--ftwrl-wait-threshold

show processlist 中的 SQL 執(zhí)行時(shí)間，如果SQL 自行時(shí)間小于ftwrl-wait-threshold設(shè)定時(shí)間，直接執(zhí)行flush tables with read lock 命令，如果SQL 執(zhí)行時(shí)間大于ftwrl-wait-threshold設(shè)定時(shí)間，則等待。

目前備份系統(tǒng)的命令使用方式是

baseDir = fmt.Sprintf("/data/mysql%d", port)
args = append(args, fmt.Sprintf("--defaults-file=%s/conf/my.cnf", baseDir))
args = append(args, fmt.Sprintf("--datadir=%s/data", baseDir))
args = append(args, fmt.Sprintf("--socket=%s/run/mysql.sock", baseDir))
args = append(args, fmt.Sprintf("--user=%s", user))
args = append(args, fmt.Sprintf("--password=%s", pwd))
args = append(args, "--slave-info")
args = append(args, fmt.Sprintf("--ftwrl-wait-timeout=%d", 250))
args = append(args, fmt.Sprintf("--open-files-limit=%d", 204800))
args = append(args, "--stream=xbstream")
args = append(args, "–backup")
args = append(args, fmt.Sprintf("--parallel=%d", parallel))
args = append(args, fmt.Sprintf("--throttle=%d", throttle))
args = append(args, "–compress")
增量備份
args = append(args, fmt.Sprintf("--incremental-lsn=%s", incrLsn))

每次備份，我們會(huì)主動(dòng)獲取incremental-lsn，為下次增量備份做準(zhǔn)備。

2. TiDB 備份效率提升

【備份工具】：Mydumper、br工具

【備份方式】：邏輯備份 + 物理機(jī)備份

【備份時(shí)間】：00:00-10:00

TiDB 官方提供了br 物理機(jī)備份工具，加上物理機(jī)備份與文件系統(tǒng)結(jié)合，備份效率也得到的大大提升，目前TiDB 4.0 以上的版本使用物理機(jī)備份+ 增量備份，需要設(shè)置gc_time 為48h，否則增量備份會(huì)報(bào)錯(cuò)。而對(duì)4.0以下的版本繼續(xù)使用Mydumper進(jìn)行備份。

3. MongoDB 備份效率提升

【備份工具】：mongodbdump + cp

【備份方式】：邏輯備份 + 物理機(jī)備份

【備份時(shí)間】：00:00-10：00

由于mongodbdump 邏輯備份對(duì)數(shù)據(jù)量大的實(shí)例備份十分困難，因此引入了MongoDB的物理備份。

物理備份實(shí)現(xiàn)邏輯

db.fsyncLock() 特性

Changed in version MongoDB: 3.2
db.fsyncLock() ensures that the data files are safe to copy using low-level backup utilities such as cp, scp, or tar. A mongod started using the copied files contains user-written data that is indistinguishable from the user-written data on the locked mongod.
Prior to MongoDB 3.2, db.fsyncLock() cannot guarantee that WiredTiger data files are safe to copy using low-level backup utilities.

db.fsyncLock() 鎖住整庫(kù)后，可以直接對(duì)MongoDB 文件進(jìn)行cp、scp或者tar 操作，因此，利用該特性進(jìn)行物理機(jī)備份。

由于需要db.fsyncLock()需要鎖整個(gè)庫(kù)，為了不影響部分業(yè)務(wù)的讀寫(xiě)分離要求，因此需要增加一個(gè)隱藏節(jié)點(diǎn)，為了節(jié)省資源，我們把其中3個(gè)副本中的一個(gè)副本作為隱藏節(jié)點(diǎn)，在任何業(yè)務(wù)需要時(shí)，可以直接轉(zhuǎn)變?yōu)榉请[藏節(jié)點(diǎn)提供服務(wù)，副本被設(shè)置為隱藏節(jié)點(diǎn)后，是不能對(duì)業(yè)務(wù)提供服務(wù)的，只做備份使用。

增加隱藏節(jié)點(diǎn)

增加隱藏節(jié)點(diǎn)
cfg = rs.conf()
cfg.members[2].priority = 0
cfg.members[2].hidden = true
cfg.members[2].votes = 1 
rs.reconfig(cfg)

隱藏節(jié)點(diǎn)需要具有投票，這樣可以減少一個(gè)實(shí)例節(jié)點(diǎn)。

全備份命令

使用db.fsyncLock() 鎖庫(kù)
獲取最新的oplog位置
next_ts=db.oplog.rs.find().sort({$natural:-1}).limit(1)
tar -cf 文件
使用 db.fsyncUnlock() 解鎖

記錄oplog 位點(diǎn)是為了增量備份做準(zhǔn)備

增量備份

增量備份是備份oplog，根據(jù)全備獲取的最新的oplog 進(jìn)行備份
使用db.fsyncLock() 鎖庫(kù)
last_ts=db.oplog.rs.find().sort({$natural:-1}).limit(1)
mongodump --host= 127.0.0.1 --port=27010 --username=mg_backup --password=123ASD123 --gzip --authenticationDatabase=admin -d local -c oplog.rs \
-q '{ts:{$gt:Timestamp("next_ts")}}' --archive=oplog.inc_2
使用 db.fsyncUnlock() 解鎖

因此，備份邏輯上也進(jìn)行了改造，對(duì)于 小于20G的實(shí)例，使用mongodbdump邏輯備份，對(duì)于大于20G 的實(shí)例使用物理機(jī)備份。由于物理機(jī)備份直接拷貝物理文件，備份速度快了很多。而邏輯增量備份是備份oplog，oplog設(shè)置基本都在50G左右，因此邏輯增量備份也能滿足需求。

物理恢復(fù)

① 全備恢復(fù)

tar -xf bull_back -C xxxx

使用空實(shí)例，不直接接入之前的副本集中

② 增量恢復(fù)

mongorestore --archive=65.gzip --port=11303 --gzip --oplogReplay

物理恢復(fù)主要用于MongoDB的定點(diǎn)恢復(fù)，日常添加從節(jié)點(diǎn)，都是使用MongoDB自身的數(shù)據(jù)同步。由于MongoDB 在公司占比份額較少，而且出現(xiàn)誤刪數(shù)據(jù)的幾率也小，自維護(hù)MongoDB 依賴，僅僅出現(xiàn)過(guò)2次MongoDB定點(diǎn)恢復(fù)的案例。

4. 性能提升總結(jié)

基于備份邏輯及備份方式的改變，備份效率提高很大，未改造前，MySQL兩天成功率才能達(dá)到98%以上，改造完畢后，MySQL備份基本在10點(diǎn)以前就能完成所有的備份，而且備份成功率能達(dá)到100%。

TiDB更改br 物理機(jī)備份后，成功率也提升至100%，而版本低于4.0以下的TiDB依舊使用Mydumper備份，但成功率也實(shí)現(xiàn)了質(zhì)的飛躍。

MongoDB自從改成物理機(jī)備份后，成功率也提升至100%。雖然MongoDB的備份文件使用率不高，但使用備份文件恢復(fù)數(shù)據(jù)多達(dá)6次以上。

3.2 文件系統(tǒng)演化

文件系統(tǒng)使用的是vivo資源的對(duì)象存儲(chǔ)系統(tǒng)。vivo對(duì)象存儲(chǔ)提供海量、安全、低成本、高可靠的云存儲(chǔ)服務(wù)，提供12個(gè)9的數(shù)據(jù)持久性，99.995%的數(shù)據(jù)可用性。提供多種語(yǔ)言SDK，開(kāi)發(fā)者可快速便捷接入對(duì)象存儲(chǔ)。

產(chǎn)品優(yōu)勢(shì)

• 服務(wù)穩(wěn)定可靠：提供12個(gè)9的數(shù)據(jù)可靠性保障。
• 存儲(chǔ)空間大：提供PB級(jí)存儲(chǔ)能力，存儲(chǔ)空間按需擴(kuò)展無(wú)上限；單個(gè)Bucket的容量無(wú)限制，單個(gè)文件（對(duì)象）最大支持48.8TB。
• 成本低：根據(jù)不同數(shù)據(jù)類(lèi)型選擇選擇不同性能存儲(chǔ)規(guī)格降低服務(wù)器成本，通過(guò)糾刪碼、數(shù)據(jù)刪重、壓縮等技術(shù)節(jié)省存儲(chǔ)空間。
• 數(shù)據(jù)安全有保障：支持桶和對(duì)象級(jí)別的權(quán)限控制，通過(guò)防盜鏈、多種加密方法保障數(shù)據(jù)安全。
• 使用便捷：可通過(guò)SDK、控制臺(tái)進(jìn)行上傳下載。

經(jīng)過(guò)一系列的改造，備份效果得到了大大的改觀，使用對(duì)象存儲(chǔ)以后，基本不再考慮文件系統(tǒng)的壓力及高可用性，省去了很多麻煩。而且對(duì)象存儲(chǔ)無(wú)法直接查看和操作備份文件，文件的獲取均需要程序操作，任何人員無(wú)法直接獲取，增加了文件安全性。

3.3 備份系統(tǒng)功能擴(kuò)展

1. 中轉(zhuǎn)機(jī)組件

MySQL 集群添加實(shí)例的流程:先把備份文件從對(duì)象存儲(chǔ)上下載到目標(biāo)物理機(jī)上、合并解壓備份文件、應(yīng)用日志、啟動(dòng)實(shí)例、配置該實(shí)例成為主庫(kù)的從庫(kù)，添加從庫(kù)實(shí)例完畢。

該添加從庫(kù)實(shí)例功能上線后，我們發(fā)現(xiàn)物理機(jī)的原住民會(huì)突然出現(xiàn)并發(fā)執(zhí)行SQL增加，業(yè)務(wù)服務(wù)訪問(wèn)數(shù)據(jù)庫(kù)變慢的情況，經(jīng)過(guò)排查發(fā)現(xiàn):備份文件在合并解壓時(shí)，會(huì)出現(xiàn)嚴(yán)重的io行為，該行為直接影響物理機(jī)上的原住民。

為了解決這個(gè)問(wèn)題，增加了中轉(zhuǎn)機(jī)，先把備份文件下載至中轉(zhuǎn)機(jī)，在中轉(zhuǎn)機(jī)上合并解壓文件，并把應(yīng)用日志后的恢復(fù)文件通過(guò)Linux的pv工具限速，傳送至目標(biāo)機(jī)器上，從而不對(duì)物理機(jī)上原住民產(chǎn)生影響。

2. 恢復(fù)模塊

恢復(fù)模塊依舊沿用之前的恢復(fù)策略，在增加中轉(zhuǎn)機(jī)的情況下，讓業(yè)務(wù)運(yùn)行更穩(wěn)定，更安全。

目前恢復(fù)模塊主要用于增加從庫(kù)實(shí)例，也應(yīng)用于已經(jīng)擴(kuò)展的自動(dòng)化遷移功能。經(jīng)備份邏輯的改造，恢復(fù)模塊相較于舊的恢復(fù)模塊，在效率、安全性上提升了很多。

3. 備份校驗(yàn)?zāi)K

備份校驗(yàn)?zāi)K是為了驗(yàn)證備份文件的有效性做的一個(gè)模塊，為了實(shí)現(xiàn)這功能，我們?cè)O(shè)計(jì)了兩套方案。

方案1

恢復(fù)實(shí)例+10分鐘同步驗(yàn)證，如果10分鐘同步主庫(kù)無(wú)報(bào)錯(cuò)，就認(rèn)為備份文件是有效的。但會(huì)消耗至少一個(gè)MySQL實(shí)例資源，同時(shí)要較久的同步時(shí)間和一致性校驗(yàn)時(shí)間，落地有成本和效率問(wèn)題，本方案未采用。

方案2

目前使用的備份校驗(yàn)標(biāo)準(zhǔn)：

① 設(shè)定備份流程：

（1）備份開(kāi)始前，如果是邏輯備份（數(shù)據(jù)小于20G），獲取所有表行數(shù)并記錄。如果是物理備份，記錄/data目錄大小

（2）備份結(jié)束后，如果是邏輯備份（數(shù)據(jù)小于20G），獲取所有表行數(shù)并記錄。如果是物理備份，記錄/data目錄大小

② 備份恢復(fù)流程：

（1）備份恢復(fù)到某個(gè)MySQL實(shí)例，物理備份額外要求執(zhí)行MySQLcheck 確保沒(méi)有壞的數(shù)據(jù)表。

（2）校驗(yàn)備份前后庫(kù)表差異，

• 一致則要求備份恢復(fù)后的庫(kù)表結(jié)構(gòu)也和備份前后一致。
• 前后不一致則不校驗(yàn)恢復(fù)后庫(kù)表結(jié)構(gòu)

（3）校驗(yàn)備份前后數(shù)據(jù)差異，邏輯備份校驗(yàn)表行數(shù)，物理備份校驗(yàn)數(shù)據(jù)目錄大小，要求偏差小于10%

我們?yōu)榱吮Ｕ虾诵臄?shù)據(jù)庫(kù)的備份文件有效性，特設(shè)定了以下標(biāo)準(zhǔn)：

1. 設(shè)定優(yōu)先級(jí)，對(duì)特定的數(shù)據(jù)庫(kù)設(shè)定較高的優(yōu)先級(jí)
2. 必須保障每月驗(yàn)證一次的頻率
3. 每個(gè)數(shù)據(jù)庫(kù)每年必須驗(yàn)證一次

4. 定點(diǎn)恢復(fù)模塊

定點(diǎn)恢復(fù)模塊主要應(yīng)用于誤刪數(shù)據(jù)后的恢復(fù)工作，該系統(tǒng)的架構(gòu)圖如下：

首先，需要與開(kāi)發(fā)人員溝通誤刪數(shù)據(jù)時(shí)間點(diǎn)，從主庫(kù)中尋找對(duì)應(yīng)的binlog 位點(diǎn)，或者是gtid信息，并在我們的內(nèi)部管理系統(tǒng)daas上的【備份管理】中選擇出指定的備份文件，并在daas管理系統(tǒng)提數(shù)據(jù)恢復(fù)工單，工單界面圖如下：

恢復(fù)位置點(diǎn)，我們有三種選擇方式，選擇無(wú)，及時(shí)恢復(fù)到某個(gè)備份文件即可，不再追binlog，gitd位點(diǎn)是用于開(kāi)啟gtid的數(shù)據(jù)庫(kù)服務(wù)，binlog位點(diǎn)是應(yīng)對(duì)未開(kāi)啟gtid的數(shù)據(jù)庫(kù)服務(wù)。在審批人（一般是該項(xiàng)目開(kāi)發(fā)的負(fù)責(zé)人）通過(guò)后，定點(diǎn)恢復(fù)模塊便對(duì)恢復(fù)機(jī)器下發(fā)命令，從對(duì)象存儲(chǔ)獲取指定的備份文件，恢復(fù)數(shù)據(jù)，通過(guò)start slave until 命令恢復(fù)至指定的位置點(diǎn)。

以下是恢復(fù)完成后的工單詳情，通過(guò)訪問(wèn)目標(biāo)ip和目標(biāo)端口來(lái)查看恢復(fù)的數(shù)據(jù)。

定點(diǎn)恢復(fù)受限于物理機(jī)磁盤(pán)限制，因?yàn)橐獞?yīng)對(duì)各種大小的數(shù)據(jù)庫(kù)，我們準(zhǔn)備了一個(gè)非常大的物理磁盤(pán)，不過(guò)該磁盤(pán)是普通的ssd，因此恢復(fù)時(shí)間上會(huì)比較慢。而且恢復(fù)時(shí)長(zhǎng)也跟數(shù)據(jù)庫(kù)的備份文件大小有關(guān)，數(shù)據(jù)庫(kù)越大，恢復(fù)越慢。由于MySQL數(shù)據(jù)庫(kù)現(xiàn)在使用了物理備份，恢復(fù)單個(gè)表只能先全庫(kù)恢復(fù)，再追位點(diǎn)，因此恢復(fù)效率比較低。如果是基于Mydumper 邏輯備份的，恢復(fù)單個(gè)表，會(huì)非?？焖?，因?yàn)橹恍枰鸦謴?fù)的表拷貝出來(lái)，即可單獨(dú)恢復(fù)。然而目前卻無(wú)法實(shí)現(xiàn)，在備份效率和定點(diǎn)恢復(fù)效率上，我們選擇了前者。

定點(diǎn)恢復(fù)只需要DBA找到具體的恢復(fù)時(shí)間點(diǎn)，然后配置恢復(fù)頁(yè)面，系統(tǒng)會(huì)自動(dòng)為我們創(chuàng)建實(shí)例，恢復(fù)至指定的時(shí)間點(diǎn)，從而恢復(fù)數(shù)據(jù)。該操作減少DBA的直接恢復(fù)操作，并且以此功能作為一個(gè)保底的數(shù)據(jù)恢復(fù)，在定點(diǎn)恢復(fù)執(zhí)行的過(guò)程中，如果DBA 有其他方案，可以直接使用另外一套方案來(lái)恢復(fù)，兩個(gè)方案同時(shí)進(jìn)行，對(duì)恢復(fù)數(shù)據(jù)增加雙層保險(xiǎn)。

目前誤刪數(shù)據(jù)還有許多事情可以去做，使用更多的恢復(fù)方案提高恢復(fù)效率。

5. 自動(dòng)化遷移模塊

自動(dòng)遷移模塊是基于備份文件實(shí)現(xiàn)的，vivo的MySQL組件使用的是物理機(jī)混合部署，磁盤(pán)使用的是4T的nvme 盤(pán)，因此會(huì)受到磁盤(pán)容量的影響。我們是多實(shí)例部署，共享cpu，內(nèi)存，磁盤(pán)空間。隨著業(yè)務(wù)的增長(zhǎng)，磁盤(pán)使用容量會(huì)慢慢的增加，我們目前設(shè)定磁盤(pán)使用88%時(shí)，便自動(dòng)提單遷移實(shí)例。之所以選擇磁盤(pán)使用率的88%，是因?yàn)槲覀兊膱?bào)警是從90%開(kāi)始，主要是為了降低磁盤(pán)方面的告警。

目標(biāo)：

• 提高物理機(jī)磁盤(pán)使用率
• 減少DBA人工遷移的工作量
• 提高遷移效率
• 單個(gè)工單形成擴(kuò)容、主從切換、域名切換、回收的閉環(huán)

選擇實(shí)例的規(guī)則：

• 從庫(kù)優(yōu)先遷移
• 磁盤(pán)使用率10%左右的優(yōu)先遷移
• 實(shí)例資源小于100G的不遷移

遷入物理機(jī)選擇規(guī)則：

獲取滿足需求的物理機(jī): 滿足 【物理機(jī)磁盤(pán)使用率】+ 【遷移實(shí)例磁盤(pán)使用量】 小于物理機(jī)磁盤(pán)使用率80%   

流程圖如下：

自動(dòng)化遷移工單圖

該功能包含擴(kuò)容節(jié)點(diǎn)、主從切換、遷移域名、回收實(shí)例等步驟。如果出現(xiàn)選擇的實(shí)例不易遷走，可以使用【更改節(jié)點(diǎn)結(jié)單】或者【回收實(shí)例結(jié)單】功能完成整個(gè)工單的閉環(huán)。

目前該項(xiàng)功能已經(jīng)投入使用，直至目前已經(jīng)提單259個(gè)，提高遷移效率達(dá)95%以上。

3.4 新備份恢復(fù)系統(tǒng)的不足

1. MongoDB shard 備份缺陷

由于MongoDB shard 引入，MongoDB shard 備份還未有更好的備份方案。目前MongoDB shard 依舊是使用物理備份，但是對(duì)數(shù)據(jù)恢復(fù)上還存在不足。在恢復(fù)至某一個(gè)時(shí)間點(diǎn)上，還需要使用oplog單獨(dú)對(duì)每個(gè)分片進(jìn)行恢復(fù)，恢復(fù)起來(lái)步驟復(fù)雜。

2. 數(shù)據(jù)恢復(fù)效率不高

數(shù)據(jù)恢復(fù)是在數(shù)據(jù)被誤刪的時(shí)候發(fā)起的操作，雖然使用頻率較低，但是該功能卻是非常重要的，目前恢復(fù)數(shù)據(jù)是基于全庫(kù)恢復(fù)+binlog重做，恢復(fù)效率較低，依舊有很多的恢復(fù)方案亟待加入，提高恢復(fù)數(shù)據(jù)的效率，減少因誤刪數(shù)據(jù)產(chǎn)生的影響。

四、總結(jié)

4.1 安全

舊系統(tǒng)主要是文件系統(tǒng)安全，由于使用的是GlusterFS文件系統(tǒng)，物理機(jī)備份主要是掛載到目標(biāo)機(jī)器上，導(dǎo)致登錄物理機(jī)后，可以不受限制的操作備份文件，非常危險(xiǎn)，雖然異地災(zāi)備文件系統(tǒng)只掛載至備份控制機(jī)，權(quán)限控制的比較嚴(yán)格，但是由于拷貝速度的限制，異地的副本已名存實(shí)亡。

使用新系統(tǒng)后，備份文件存儲(chǔ)于多個(gè)機(jī)房之中，某個(gè)機(jī)房全部宕機(jī)，也不影響備份文件的讀取，因此對(duì)備份文件保護(hù)得到了加強(qiáng)。同時(shí)由于對(duì)象存儲(chǔ)系統(tǒng)未使用掛載形式，因此，DBA和系統(tǒng)工程師無(wú)法下載備份文件，也無(wú)法操作備份文件系統(tǒng)，讓備份文件更加安全。

4.2 效率

受限于舊文件系統(tǒng)效率寫(xiě)入以及邏輯備份速度，MySQL 備份2天才能完成一輪備份，MongoDB 由于實(shí)例太大，受限于mongodbdump 本身的特性，備份時(shí)間很長(zhǎng)，而且很容易失敗。雖然優(yōu)化后，改成ssd 盤(pán)備份，但受限于盤(pán)的大小，MongoDB 的備份效率依舊不好。

通過(guò)更換文件系統(tǒng)，以及備份策略，極大的提高了備份效率，備份從之前的2天完成備份，提高至10個(gè)小時(shí)完成備份。

自動(dòng)化遷移在減少DBA選擇實(shí)例的同時(shí)，也能形成完整的閉環(huán)，DBA在操作的時(shí)候只需要根據(jù)工單的流程即可，極大的提高了工作效率。

4.3功能模塊擴(kuò)展

自從使用Java 語(yǔ)言后，并且有專(zhuān)門(mén)的 Java 開(kāi)發(fā)人員的介入，新功能需求得到了實(shí)現(xiàn)，經(jīng)過(guò)多輪的優(yōu)化，目前新備份恢復(fù)系統(tǒng)運(yùn)行非常穩(wěn)定?；趥浞菸募?，我們擴(kuò)展了定點(diǎn)恢復(fù)模塊、自動(dòng)化遷移方案、以及機(jī)器故障自動(dòng)發(fā)起遷移等功能，極大的提高DBA的工作效率，讓我們有更多的時(shí)間去解決企業(yè)的痛點(diǎn)。