MongoDB的數據庫如何備份和恢復？

瞭解更多詳情點擊原文連接

 

MongoDB數據庫如何備份？恢復mongodb數據庫應如何操做？最近數據庫多災多難，這些問題也成爲開發者關注的重點。2016年12月爆出MongoDB數據庫安全問題（見MongoDB黑客贖金事件解讀及防範）。2017年1月又被爐石傳說數據庫故障給刷屏了。做爲一個數據庫行業從業人員，看到這個新聞是否是還應該乾點什麼？恩，頗有必要再從新審視一下咱們的數據庫有沒有作好容災，藉此機會給你們普及一下MongoDB數據庫的備份和恢復手段。

 

 

MongoDB數據庫備份手段

全量邏輯備份/恢復

Mongodump/Mongorestore

對於數據量比較小的場景，使用官方的mongodump/mongorestore工具進行全量的備份和恢復就足夠了。mongodump能夠連上一個正在服務的mongod節點進行邏輯熱備份。其主要原理是遍歷全部集合，而後將文檔一條條讀出來，支持併發dump多個集合，而且支持歸檔和壓縮，能夠輸出到一個文件（或標準輸出）（對原理感興趣能夠參見兩篇文章Mongodump的archive（歸檔）模式原理解析以及Mongorestore的archive(歸檔)模式恢復原理解析）。一樣，mongorestore則是連上一個正在服務的mongod節點進行邏輯恢復。其主要原理是將備份出來的數據再一條條寫回到數據庫中。

對性能的影響

mongodump執行過程因爲會遍歷全部數據，所以會對MongoDB性能有影響，最好在備節點執行（最好是hidden，需檢查備節點數據同步是否正常）。

獲取一致的數據快照

在mongodump執行過程當中因爲數據庫還有新的修改，直接運行dump出來的結果不是一個一致的快照，須要使用一個『--oplog』的選項來將這個過程當中的oplog也一塊dump下來（使用mongorestore進行恢復時對應要使用--oplogReplay選項對oplog進行重放）。而因爲MongoDB的oplog是一個固定大小的特殊集合，當oplog集合達到配置的大小時舊的oplog會被滾掉覺得新的oplog騰出空間。在使用『--oplog』選項進行dump時，mongodump會在dump集合數據前獲取當時最新的oplog時間點，並在集合數據dump完畢以後再次檢查這個時間點的oplog是否還在，若是dump過程很長，oplog空間又不夠，oplog被滾掉就會dump失敗。所以在dump前最好檢查一下oplog的配置大小以及目前oplog的增加狀況（可結合業務寫入量及oplog平均大小進行粗略估計），確保dump不會失敗。目前咱們阿里雲MongoDB服務針對oplog作了彈性擴縮容的優化，可以確保在邏輯備份過程當中oplog不被滾掉，必定可以備份成功。

索引的備份和恢復

對於集合數據，mongodump出來的結果是一個個bson文件。而對於集合的索引，則是描述在一個metadata的json文件裏，裏面還包含建立集合時所使用的選項。在使用mongorestore進行恢復時，會在集合數據恢復完畢以後進行對應的索引建立。

全量物理備份/恢復

對於數據量很大的場景，若是使用mongodump/mongorestore進行備份和恢復，須要的時間可能會很長。對於備份來講，最主要的問題就是備份所需時間越長，oplog被滾掉的概率就越大，備份失敗的概率也就越大。而對於恢復來講，因爲恢復過程還涉及到索引的建立，若是除了數據量大，還有不少索引，所需花費的時間就更長了。遇到像爐石這種數據災難，恢復時間固然是越短越好，畢竟在遊戲行業分分鐘的流水都很可觀。這時候就須要物理備份出場了，物理備份，顧名思義就是經過物理拷貝數據文件實現備份。在恢復時能夠直接使用物理備份拷貝出來的數據文件，直接啓動mongod。物理備份最大的好處是速度快，恢復時也不須要再建索引。

實施方法

物理備份經過拷貝數據文件來實現，這要求全部被拷貝的數據文件必須是一個一致的數據快照。所以物理備份的實施方法和MongoDB採用的存儲引擎有關，而且，根據是否配置MongoDB打開了Journal，在實施的細節上會有一些不一樣，具體可參考官方文檔。無論使用何種存儲引擎，在3.2版本以後，均可以用如下方法實現物理備份：

1.    經過mongoshell執行如下命令以確保全部的寫操做都flush到磁盤並禁止新的寫入：

db.fsyncLock();

2.    利用底層文件系統層或邏輯卷的快照功能對MongoDB的數據目錄作快照，或直接經過cp、scp、tar等命令拷貝數據目錄。

3.    仍是在剛纔的mongoshell上（這裏須要保證和剛剛是同一個鏈接），執行如下命令以從新容許新的寫入：

db.fsyncUnLock();

因爲執行db.fsyncLock()會加數據庫的全局寫鎖，這時數據庫會處於一個不可訪問的狀態，所以物理備份最好也在備節點上執行（最好是hidden，注意一樣須要確保物理備份完成以後節點的oplog能追上主節點）。目前咱們阿里雲MongoDB團隊已經研發出了無需停寫服務的物理熱備份手段，相信很快就可讓你們用上，盡請期待！

增量備份

MongoDB的增量備份能夠經過持續抓取oplog來實現，這個目前沒有現成的工具能夠利用，須要本身代碼實現。抓取oplog主要的難題也和使用mongodump進行全量備份同樣，需確保要抓取的oplog不被滾掉。目前咱們阿里雲MongoDB服務實現了自動增量備份的功能，結合全量備份能夠實現任意時間點恢復功能。

Sharding的備份/恢復

爐石是不分服的，所以它後面也有多是使用分佈式數據庫。對於分佈式數據庫來講，備份和恢復比單機數據庫更加複雜。分佈式數據庫包含多個節點，而且一般包含不一樣角色的節點。以MongoDB的Sharding集羣爲例，它包含一個保存元數據的config server以及若干個保存數據的shard。其中最主要的元數據就是數據在shard之間的分佈狀況。對於多個節點的備份，其中一個難題是保證全部節點備份的數據是同一個時間點的，常規採用的手段是中止外部寫入後進行備份，這在互聯網服務中顯然不可接受。退而求其次，能夠在中止接受同步的備節點上進行備份，這樣能夠獲得一個時間大體接近的備份。另一個難題是各數據節點之間一般存在數據遷移，而數據遷移就涉及到起碼2個以上數據節點的數據修改以及元數據節點的數據修改，若是在備份過程當中發生數據遷移，很難保證備份出來的數據和元數據是一個一致的狀態。所以一般在備份過程當中須要關閉數據遷移。MongoDB官方的文檔指導步驟就是採用這個思路，先關閉負責數據遷移的balancer，而後依次在config server和各個shard的備節點上進行備份。關閉數據遷移最大的問題是關閉期間集羣沒法實現數據均衡，除了會影響集羣的訪問性能外，還形成資源的浪費，這在數據量較大，所需備份時間較長時可能形成比較大的影響。

針對這兩大難題，阿里云云數據庫MongoDB團隊研發了不須要停外部寫，而且無需關數據遷移的Sharding備份手段，可以實現『任意』時間點恢復。

阿里云云數據庫MongoDB備份服務

阿里云云數據庫MongoDB服務提供自動備份/恢復功能，默認天天爲數據進行全量備份，而且自動抓取oplog進行增量備份。用戶能夠在控制檯自定義備份策略以及進行恢復。

 

恢復時能夠選擇某一個備份集或某一個時間點克隆出一個新的實例，能夠在新實例上進行數據校驗，等校驗沒問題後切換到新實例。此外，全量備份的數據還提供下載功能，用戶也能夠選擇下載備份集到本地後恢復到一個臨時實例進行數據校驗。

總結

以上信息能夠幫助你們對MongoDB的備份/恢復手段有一個大概的認識。從省心的角度考慮，仍是建議直接使用阿里云云數據庫MongoDB服務，咱們有自動化的備份/恢復服務，靈活的備份策略，只需點點鼠標就能實現任意時間點恢復、物理熱備份、Sharding備份/恢復，今後再也不爲數據庫容災發愁。

 

 

瞭解更多詳情點擊原文連接

http://click.aliyun.com/m/25367/ 專訪 | 楊強教授談CCAI、深度學習泡沫與人工智能入門


http://click.aliyun.com/m/25368/ CCAI 2017 | 小數據學習對人工智能究竟有着怎樣的影響？


http://click.aliyun.com/m/25380/ MySQL 集羣服務簡介


http://click.aliyun.com/m/25382/ C#鏈接mysql數據庫並進行查詢


http://click.aliyun.com/m/25383/ MongoDB的數據庫如何備份和恢復？


http://click.aliyun.com/m/25384/ 如何設計一個牛掰的大型項目架構？


http://click.aliyun.com/m/25385/ 大數據常見術語表


http://click.aliyun.com/m/25386/ MySQL存儲引擎之Spider內核深度解析


http://click.aliyun.com/m/25388/ 阿里巴巴1582.73億背後的持續交付如何玩


http://click.aliyun.com/m/25389/ 天然語言處理的通用深度學習方法


http://click.aliyun.com/m/25390/ 雲計算基礎設施持續集成實踐


http://click.aliyun.com/m/25391/ 人類河流文明 - 數據的流動與生態的重要性


http://click.aliyun.com/m/25398/ 7月6日雲棲精選夜讀：淺談應用性能測試 PTS


http://click.aliyun.com/m/25406/ 數據庫SQL優化大總結之 百萬級數據庫優化方案


http://click.aliyun.com/m/25407/ 哪些手遊網遊最適合碼農？


http://click.aliyun.com/m/25408/ 人工智能浪潮之下普通程序員如何入門AI？


http://click.aliyun.com/m/25409/ 數據庫配置不當美國2億選民數據泄漏_這鍋誰背?