作者：vivo 網際網路資料庫團隊 - Han Chaobing

介紹 vivo 資料庫備份恢復功能的演化，以及對備份檔案的功能擴充套件。

一、概述

vivo網際網路領域擁有的資料庫元件分別為  MySQL、 MongoDB、 TiDB 等，其中 MySQL叢集佔比絕大部分，  MongoDB 叢集佔比小部分，  TiDB 叢集佔比更小。為了介紹方便，本文把改造前的資料庫備份恢復系統稱為舊備份恢復系統，改造後的資料庫備份恢復系統稱為新備份恢復系統。我們將從舊的架構系統開始，發現其不足，慢慢的最佳化形成新的系統架構。

二、舊備份恢復系統

舊備份恢復系統架構圖

舊備份恢復系統是基於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() 特性

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 開發人員的介入，新功能需求得到了實現，經過多輪的最佳化，目前新備份恢復系統執行非常穩定。基於備份檔案，我們擴充套件了定點恢復模組、自動化遷移方案、以及機器故障自動發起遷移等功能，極大的提高DBA的工作效率，讓我們有更多的時間去解決企業的痛點。