一、概述

vivo互聯網領域擁有的數據庫組件分別為 MySQL、MongoDB、TiDB 等，其中MySQL集群占比絕大部分，  MongoDB 集群占比小部分， TiDB 集群占比更小。目前備份存儲14天，磁盤總量為1PB。為了介紹方便，本文把改造前的數據庫備份恢復系統稱為舊備份恢復系統，改造后的數據庫備份恢復系統稱為新備份恢復系統。我們將從舊的架構系統開始，發現其不足，慢慢的優化形成新的系統架構。

二、舊備份恢復系統

舊備份恢復系統架構圖

舊備份恢復系統是基于Python 語言開發的，使用分布式文件系統GlusterFS，Python作為開發語言，使用任務調度模塊Celery下發備份和恢復任務。或許由于之前開發時間緊迫，在服務可用性和Redis組件高可用性上，并未做過多的工作。若出現物理機宕機或網絡等問題，將直接影響備份系統的穩定性。

2.1 備份模塊

備份模塊是舊備份恢復系統的一個主要功能服務，主要用于MySQL、TiDB、MongoDB 組件的備份調度、備份等任務，來完成每日的數據庫備份。舊備份恢復系統主要使用的是邏輯備份，在僅有5臺物理機上負責備份任務的發起和執行，由于互聯網的體量大，數據庫全備一次需要2天的時間，因此備份的成功率是按照2天統計。由于文件系統的高負載，以及備份中鎖等原因也會出現備份調度失敗的情況，導致整個物理機上的實例不能再次發起備份，需要手工維護才能繼續備份，系統維護上也非常麻煩。

2.2 組件備份介紹

MySQL和TiDB的備份

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

【備份方式】：邏輯備份 + 物理機備份

邏輯備份 Mydumper 工具

Mydumper 是一款社區開源的邏輯備份工具。該工具主要由 C 語言編寫，目前由 MySQL 、Facebook 等公司人員開發維護。

參考官方介紹，Mydumper 主要有以下幾點特性：

• 支持多線程導出數據，速度更快。
• 支持一致性備份。
• 支持將導出文件壓縮，節約空間。
• 支持多線程恢復。
• 支持以守護進程模式工作，定時快照和連續二進制日志。
• 支持按照指定大小將備份文件切割。
• 數據與建表語句分離。

Mydumper的主要工作步驟：

1. 主線程 flush tables with read lock, 施加全局只讀鎖，以阻止dml語句寫入，保證數據的一致性。
2. 讀取當前時間點的二進制日志文件名和日志寫入的位置并記錄在metadata文件中，以供恢復使用。
3. start transaction with consistent snapshot; 開啟讀一致事務。
4. 啟用n個（線程數可以指定，默認是4）dump線程導出表和表結構。
5. 備份非事務類型的表。
6. 主線程 unlock tables，備份完成非事務類型的表之后，釋放全局只讀鎖。
7. 基于事務dump innodb tables。
8. 事務結束。

基于Mydumper 以上的特性，PingCAP公司針對 TiDB 的特性進行了優化，Mydumper 包含在 tidb-enterprise-tools 安裝包中。對于 TiDB 可以設置 tidb_snapshot 的值指定備份數據的時間點，從而保證備份的一致性，而不是通過 FLUSH TABLES WITH READ LOCK 來保證備份一致性。使用 TiDB 的隱藏列 _tidb_rowid 優化了單表內數據的并發導出性能。TiDB 官方早起提供了Mydumper備份工具，后期提供了BR 物理機備份工具，然而物理機備份受限制于文件系統，在GlusterFS 文件系統下，只能使用Mydumper 做邏輯備份。

Mydumper 備份屬于邏輯備份，需要讀全表，因此備份效率會低很多。同一個數據庫，在文件系統不變的情況下，邏輯備份和物理備份的對比。

從該統計可以看出，邏輯備份時間很不穩定，Mydumper 備份最短一次是6.5個小時，最長在23小時，而物理機備份時間基本維持在7個小時左右。

物理機備份Xtrabackup工具

Xtrabackup是Percona團隊開發的用于MySQL數據庫物理熱備份的開源備份工具，具有備份速度快、支持備份數據壓縮、自動校驗備份數據、支持流式輸出、備份過程中幾乎不影響業務等特點，是目前各個云廠商普遍使用的MySQL備份工具。

由于物理機備份未使用壓縮和打包，備份的文件受限于表的大小，在備份特別大的表時，總會出現文件系統分布不均勻的情況，大部分磁盤在80%的時候，某些磁盤的使用容量卻超過95%，需要經常登錄文件系統刪除備份文件來消除告警。另外物理備份配置比例較小，備份占比不高。后續雖然經過一些了優化（增加打包和文件分拆功能），解決了磁盤分布不均的問題。但備份成功率提升不明顯。

MongoDB 備份

【備份工具】：mongodbdump

【備份方式】：邏輯備份

【備份時間】：全天時間段

mongodbdump 是MongoDB 官方提供的備份程序，對于小于100G以內的備份還能輕松應付，但對于大于100G的實例雖然也能備份，不過備份時間會比較長。vivo目前有幾十個大于1T的實例，備份難度可想而知，備份成功率很低。有些MongoDB 實例因為太大，導致從未成功過。2天的備份成功率基本在20%左右，哪怕統計一周的成功率也無法達到40%，大于1T的MongoDB 實例，因為文件系統過慢，總是出現備份一半就出現失敗，雖經過多次優化，哪怕是把備份盤放置本地盤，再拷貝至文件系統，雖然備份成功率有所提高，但成功率依舊很差，而且還需要經常手工維護。

2.3 恢復模塊

恢復模塊也是基于Python開發，由Celery 模塊調度恢復策略，根據已配置的數據庫備份方式，選擇相應的邏輯和物理機恢復。

邏輯恢復是直接使用備份文件對目標庫進行恢復，不過邏輯恢復很慢，之前做過一次上T的數據庫恢復，竟然恢復了1天左右的時間。不過邏輯備份也是有好處的，在恢復單個表時，可以直接把該表的文件系統拷貝出來，直接使用myloader程序直接恢復，可以非常快速的恢復單表，這比物理機恢復單個表要快很多。不過這里的恢復需要手工操作，代碼并未實現該項功能。。

物理機恢復是直接使用文件系統掛載的方式，直接把文件系統掛載至目標機器，把備份的文件拷貝紙目標機器來恢復數據，功能相對簡單一些，由于是直接拷貝文件，恢復速度相對會快一些。

恢復模塊僅用于增加從庫實例和延遲從庫，未做到任一時間點的恢復，功能相對單一。

2.4 文件系統

GlusterFS系統是一個可擴展的網絡文件系統，相比其他分布式文件系統，GlusterFS具有高擴展性、高可用性、高性能、可橫向擴展等特點，并且其沒有元數據服務器的設計，讓整個服務沒有單點故障的隱患。當客戶端訪問GlusterFS存儲時，首先程序通過訪問掛載點的形式讀寫數據，對于用戶和程序而言，集群文件系統是透明的，用戶和程序根本感覺不到文件系統是本地還是在遠程服務器上。讀寫操作將會被交給VFS(Virtual File System)來處理，VFS會將請求交給FUSE內核模塊，而FUSE又會通過設備/dev/fuse將數據交給GlusterFS Client。最后經過GlusterFS Client的計算，并最終經過網絡將請求或數據發送到GlusterFS Server上。

vivo的備份模塊使用的GlusterFS 文件系統，分別在兩個區域的機房中。其中A機房是用于數據庫備份和恢復，B機房主要用于異地災備，增加備份文件的安全性。

A機房的文件系統主要掛載至備份恢復的主控機上，并且A機房文件系統也會掛載到需要物理備份的物理機上。數據庫的物理機任何DBA人員均可登錄，只要登錄該機器上，便可以操作任一備份文件，這對于備份文件是十分危險的；由于A機房是單機房，存在單機房故障的可能，基于以上兩點，B機房就應運而生了。

B機房的文件系統只掛載至備份恢復機器的主控機上，并且把A機房的備份文件拷貝至B機房，同時管控備份恢復的主控機權限，便可以確保備份文件系統的安全性?；诖?，備份恢復主控機及B機房物理機權限只有2個人有權限訪問，從而確保備份文件的安全性。

2.5 Copy 模塊

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

A機房的文件系統用于數據庫直接備份，B機房的文件系統中的數據，是由A機房通過Copy程序拷貝過來，在B機房保留一份副本。由于A機房承接備份和恢復兩大功能，而且還要應用于拷貝文件至B機房，還要定時刪除過期的備份文件，由此可知A機房的文件系統壓力將有多大，這也是直接導致Copy程序效率將有多差，最終結果是B機房的文件要遠遠落后A機房，導致B機房異地備份名存實亡，Copy模塊也變得形同虛設。

2.6 舊備份恢復系統存在問題

1. 效率不足

MySQL 兩天才能完成一次全備份，而且恢復實例時間也比較長，不能滿足日常恢復實例的時間要求。

MongoDB 大容量數據庫比較多，而且邏輯備份已經無法應付現在的場景，超過50%以上的MongoDB集群已無法成功備份。

2. 舊功能不足

舊備份恢復系統目前只有 備份模塊、恢復模塊、Copy模塊，功能單一，已經不能滿足互聯網領域的快速發展。

備份系統是Python代碼完成的，最初開發未考慮高可用，邏輯復雜，維護困難。

3. 文件系統方面

① 文件系統權限控制較弱，不能達到安全要求

• A機房文件系統會有多處掛載，導致備份文件安全無法得到保障

② 文件系統壓力較大，文件系統已經不堪重負

③ 異地災備形同虛設

• 受文件系統讀寫的限制，異地災備的文件系統存儲的都是幾天之前的備份文件

三、新備份恢復系統

基于Python開發的舊備份恢復系統存在許多缺點，最后引入Java 開發人員和對象存儲，對備份系統進行全方位的改造，經過一系列改進，互聯網領域目前的備份系統架構圖如下：

3.1 新備份恢復系統效率的提升

新備份恢復系統改善

Java 語言 + Redis cluster 

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

1. MySQL備份效率提升

【備份工具】：Mydumper + Xtrabackup

【備份方式】：邏輯備份 + 物理機備份

【備份策略】：備份不再受限于文件系統的影響，為了快速備份、對于數據庫data目錄存儲大于20G使用物理備份，小于20G的使用邏輯備份。

【備份時間】：00-10 之間就能完成當天的備份，大大的提高了備份效率。

在互聯網領域數據庫新的備份系統中，MySQL備份恢復采用的是邏輯備份與恢復、物理備份與恢復并存的模式，根據集群大小區分邏輯備份與物理備份。邏輯備份與恢復采用的工具是Mydumper 和 myloader，物理備份采用的是對Xtrabackup進行包裝過的工具Xtrabackup_agent（主要是對備份文件上傳至對象存儲以及恢復從對象存儲下載備份文件進行包裝以及流式備份的包裝）。

物理機備份在最后階段會獲取整個數據庫的元數據鎖，在日常的備份過程中經常會出現waiting_for的告警，經分析得知，大數據在對特定的表采集時，未釋放元數據鎖，而新的采集又要獲取被備份系統已經持有的元數據鎖，因此夜間的備份會告警出來，影響值班人員的休息，而且由于大數據采集SQL因為非常慢，經常與備份產生沖突，為了避免該沖突，備份增加 --ftwrl-wait-timeout參數，為了減少waiting_for的告警，目前的設置并不能避免waiting_for的告警，還需要優化慢SQL語句，才能做到治標治本。

--ftwrl-wait-timeout

指明執行flush tables with read lock前的等待時間，0表示不等待直接執行鎖表命令，單位是s，若超過此參數設置的時間后還存在長時間執行的查詢，則Xtrabackup終止運行。

--ftwrl-wait-threshold

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

目前備份系統的命令使用方式是

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))

每次備份，我們會主動獲取incremental-lsn，為下次增量備份做準備。

2. TiDB 備份效率提升

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

【備份方式】：邏輯備份 + 物理機備份

【備份時間】：00:00-10:00

TiDB 官方提供了br 物理機備份工具，加上物理機備份與文件系統結合，備份效率也得到的大大提升，目前TiDB 4.0 以上的版本使用物理機備份+ 增量備份，需要設置gc_time 為48h，否則增量備份會報錯。而對4.0以下的版本繼續使用Mydumper進行備份。

3. MongoDB 備份效率提升

【備份工具】：mongodbdump + cp

【備份方式】：邏輯備份 + 物理機備份

【備份時間】：00:00-10：00

由于mongodbdump 邏輯備份對數據量大的實例備份十分困難，因此引入了MongoDB的物理備份。

物理備份實現邏輯

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() 鎖住整庫后，可以直接對MongoDB 文件進行cp、scp或者tar 操作，因此，利用該特性進行物理機備份。

由于需要db.fsyncLock()需要鎖整個庫，為了不影響部分業務的讀寫分離要求，因此需要增加一個隱藏節點，為了節省資源，我們把其中3個副本中的一個副本作為隱藏節點，在任何業務需要時，可以直接轉變為非隱藏節點提供服務，副本被設置為隱藏節點后，是不能對業務提供服務的，只做備份使用。

增加隱藏節點

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

隱藏節點需要具有投票，這樣可以減少一個實例節點。

全備份命令

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

記錄oplog 位點是為了增量備份做準備

增量備份

增量備份是備份oplog，根據全備獲取的最新的oplog 進行備份
使用db.fsyncLock() 鎖庫
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() 解鎖

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

物理恢復

① 全備恢復

tar -xf bull_back -C xxxx

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

② 增量恢復

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

物理恢復主要用于MongoDB的定點恢復，日常添加從節點，都是使用MongoDB自身的數據同步。由于MongoDB 在公司占比份額較少，而且出現誤刪數據的幾率也小，自維護MongoDB 依賴，僅僅出現過2次MongoDB定點恢復的案例。

4. 性能提升總結

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

TiDB更改br 物理機備份后，成功率也提升至100%，而版本低于4.0以下的TiDB依舊使用Mydumper備份，但成功率也實現了質的飛躍。

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

3.2 文件系統演化

文件系統使用的是vivo資源的對象存儲系統。vivo對象存儲提供海量、安全、低成本、高可靠的云存儲服務，提供12個9的數據持久性，99.995%的數據可用性。提供多種語言SDK，開發者可快速便捷接入對象存儲。

產品優勢

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

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

3.3 備份系統功能擴展

1. 中轉機組件

MySQL 集群添加實例的流程:先把備份文件從對象存儲上下載到目標物理機上、合并解壓備份文件、應用日志、啟動實例、配置該實例成為主庫的從庫，添加從庫實例完畢。

該添加從庫實例功能上線后，我們發現物理機的原住民會突然出現并發執行SQL增加，業務服務訪問數據庫變慢的情況，經過排查發現:備份文件在合并解壓時，會出現嚴重的io行為，該行為直接影響物理機上的原住民。

為了解決這個問題，增加了中轉機，先把備份文件下載至中轉機，在中轉機上合并解壓文件，并把應用日志后的恢復文件通過Linux的pv工具限速，傳送至目標機器上，從而不對物理機上原住民產生影響。

2. 恢復模塊

恢復模塊依舊沿用之前的恢復策略，在增加中轉機的情況下，讓業務運行更穩定，更安全。

目前恢復模塊主要用于增加從庫實例，也應用于已經擴展的自動化遷移功能。經備份邏輯的改造，恢復模塊相較于舊的恢復模塊，在效率、安全性上提升了很多。

3. 備份校驗模塊

備份校驗模塊是為了驗證備份文件的有效性做的一個模塊，為了實現這功能，我們設計了兩套方案。

方案1

恢復實例+10分鐘同步驗證，如果10分鐘同步主庫無報錯，就認為備份文件是有效的。但會消耗至少一個MySQL實例資源，同時要較久的同步時間和一致性校驗時間，落地有成本和效率問題，本方案未采用。

方案2

目前使用的備份校驗標準：

① 設定備份流程：

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

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

② 備份恢復流程：

（1）備份恢復到某個MySQL實例，物理備份額外要求執行MySQLcheck 確保沒有壞的數據表。

（2）校驗備份前后庫表差異，

• 一致則要求備份恢復后的庫表結構也和備份前后一致。
• 前后不一致則不校驗恢復后庫表結構

（3）校驗備份前后數據差異，邏輯備份校驗表行數，物理備份校驗數據目錄大小，要求偏差小于10%

我們為了保障核心數據庫的備份文件有效性，特設定了以下標準：

1. 設定優先級，對特定的數據庫設定較高的優先級
2. 必須保障每月驗證一次的頻率
3. 每個數據庫每年必須驗證一次

4. 定點恢復模塊

定點恢復模塊主要應用于誤刪數據后的恢復工作，該系統的架構圖如下：

首先，需要與開發人員溝通誤刪數據時間點，從主庫中尋找對應的binlog 位點，或者是gtid信息，并在我們的內部管理系統daas上的【備份管理】中選擇出指定的備份文件，并在daas管理系統提數據恢復工單，工單界面圖如下：

恢復位置點，我們有三種選擇方式，選擇無，及時恢復到某個備份文件即可，不再追binlog，gitd位點是用于開啟gtid的數據庫服務，binlog位點是應對未開啟gtid的數據庫服務。在審批人（一般是該項目開發的負責人）通過后，定點恢復模塊便對恢復機器下發命令，從對象存儲獲取指定的備份文件，恢復數據，通過start slave until 命令恢復至指定的位置點。

以下是恢復完成后的工單詳情，通過訪問目標ip和目標端口來查看恢復的數據。

定點恢復受限于物理機磁盤限制，因為要應對各種大小的數據庫，我們準備了一個非常大的物理磁盤，不過該磁盤是普通的ssd，因此恢復時間上會比較慢。而且恢復時長也跟數據庫的備份文件大小有關，數據庫越大，恢復越慢。由于MySQL數據庫現在使用了物理備份，恢復單個表只能先全庫恢復，再追位點，因此恢復效率比較低。如果是基于Mydumper 邏輯備份的，恢復單個表，會非?？焖?，因為只需要把恢復的表拷貝出來，即可單獨恢復。然而目前卻無法實現，在備份效率和定點恢復效率上，我們選擇了前者。

定點恢復只需要DBA找到具體的恢復時間點，然后配置恢復頁面，系統會自動為我們創建實例，恢復至指定的時間點，從而恢復數據。該操作減少DBA的直接恢復操作，并且以此功能作為一個保底的數據恢復，在定點恢復執行的過程中，如果DBA 有其他方案，可以直接使用另外一套方案來恢復，兩個方案同時進行，對恢復數據增加雙層保險。

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

5. 自動化遷移模塊

自動遷移模塊是基于備份文件實現的，vivo的MySQL組件使用的是物理機混合部署，磁盤使用的是4T的nvme 盤，因此會受到磁盤容量的影響。我們是多實例部署，共享cpu，內存，磁盤空間。隨著業務的增長，磁盤使用容量會慢慢的增加，我們目前設定磁盤使用88%時，便自動提單遷移實例。之所以選擇磁盤使用率的88%，是因為我們的報警是從90%開始，主要是為了降低磁盤方面的告警。

目標：

• 提高物理機磁盤使用率
• 減少DBA人工遷移的工作量
• 提高遷移效率
• 單個工單形成擴容、主從切換、域名切換、回收的閉環

選擇實例的規則：

• 從庫優先遷移
• 磁盤使用率10%左右的優先遷移
• 實例資源小于100G的不遷移

遷入物理機選擇規則：

獲取滿足需求的物理機: 滿足 【物理機磁盤使用率】+ 【遷移實例磁盤使用量】 小于物理機磁盤使用率80%   

流程圖如下：

自動化遷移工單圖

該功能包含擴容節點、主從切換、遷移域名、回收實例等步驟。如果出現選擇的實例不易遷走，可以使用【更改節點結單】或者【回收實例結單】功能完成整個工單的閉環。

目前該項功能已經投入使用，直至目前已經提單259個，提高遷移效率達95%以上。

3.4 新備份恢復系統的不足

1. MongoDB shard 備份缺陷

由于MongoDB shard 引入，MongoDB shard 備份還未有更好的備份方案。目前MongoDB shard 依舊是使用物理備份，但是對數據恢復上還存在不足。在恢復至某一個時間點上，還需要使用oplog單獨對每個分片進行恢復，恢復起來步驟復雜。

2. 數據恢復效率不高

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

四、總結

4.1 安全

舊系統主要是文件系統安全，由于使用的是GlusterFS文件系統，物理機備份主要是掛載到目標機器上，導致登錄物理機后，可以不受限制的操作備份文件，非常危險，雖然異地災備文件系統只掛載至備份控制機，權限控制的比較嚴格，但是由于拷貝速度的限制，異地的副本已名存實亡。

使用新系統后，備份文件存儲于多個機房之中，某個機房全部宕機，也不影響備份文件的讀取，因此對備份文件保護得到了加強。同時由于對象存儲系統未使用掛載形式，因此，DBA和系統工程師無法下載備份文件，也無法操作備份文件系統，讓備份文件更加安全。

4.2 效率

受限于舊文件系統效率寫入以及邏輯備份速度，MySQL 備份2天才能完成一輪備份，MongoDB 由于實例太大，受限于mongodbdump 本身的特性，備份時間很長，而且很容易失敗。雖然優化后，改成ssd 盤備份，但受限于盤的大小，MongoDB 的備份效率依舊不好。

通過更換文件系統，以及備份策略，極大的提高了備份效率，備份從之前的2天完成備份，提高至10個小時完成備份。

自動化遷移在減少DBA選擇實例的同時，也能形成完整的閉環，DBA在操作的時候只需要根據工單的流程即可，極大的提高了工作效率。

4.3功能模塊擴展

自從使用Java 語言后，并且有專門的 Java 開發人員的介入，新功能需求得到了實現，經過多輪的優化，目前新備份恢復系統運行非常穩定?；趥浞菸募覀償U展了定點恢復模塊、自動化遷移方案、以及機器故障自動發起遷移等功能，極大的提高DBA的工作效率，讓我們有更多的時間去解決企業的痛點。