MongoDB備份恢復筆記

1、全量邏輯備份/恢復 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進行恢復時，會在集合數據恢復完畢之后進行對應的索引創建。

2、全量物理備份/恢復

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

實施方法

物理備份通過拷貝數據文件來實現，這要求所有被拷貝的數據文件必須是一個一致的數據快照。因此物理備份的實施方法和MongoDB采用的存儲引擎有關，并且，根據是否配置MongoDB打開了Journal，在實施的細節上會有一些不同，具體可參考官方文檔。不管使用何種存儲引擎，在3.2版本之后，都可以用以下方法實現物理備份：

1. 通過mongoshell執行以下命令以確保所有的寫操作都flush到磁盤并禁止新的寫入：

db.fsyncLock();

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

2. 還是在剛才的mongoshell上（這里需要保證和剛剛是同一個連接），執行以下命令以重新允許新的寫入：

db.fsyncUnLock();

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

增量備份

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

3、Sharding的備份/恢復

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