建站
咨詢
售后
建站咨詢
新聞中心
看到這個消息，我的***反應是重新翻出塵封已久的ipad，裝上爐石準備上線領補償。等等，作為一個數(shù)據(jù)庫行業(yè)從業(yè)人員，是不是還應該干點什么?恩，很有必要再重新審視一下我們的數(shù)據(jù)庫有沒有做好容災，否則，今天你看別人熱鬧，明天可能就別人看你熱鬧了。借此機會我想給大家普及一下MongoDB數(shù)據(jù)庫的備份和恢復手段(當然爐石傳說應該不一定是使用MongoDB作為數(shù)據(jù)庫)，以幫助大家做好容災，過個好年。同時，我也為我們阿里云MongoDB服務做下廣告，我們的MongoDB服務擁有完善的自動備份/恢復功能，靈活的備份策略，好用的恢復到任意時間點功能。我們的備份存放了多份副本，可靠性達10個9，請大家放心使用!
站在用戶的角度思考問題，與客戶深入溝通，找到濰城網(wǎng)站設計與濰城網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網(wǎng)站制作、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、申請域名、虛擬空間、企業(yè)郵箱。業(yè)務覆蓋濰城地區(qū)。
MongoDB數(shù)據(jù)庫備份手段
全量邏輯備份/恢復
Mongodump/Mongorestore
對于數(shù)據(jù)量比較小的場景，使用官方的mongodump/mongorestore工具進行全量的備份和恢復就足夠了。mongodump可以連上一個正在服務的mongod節(jié)點進行邏輯熱備份。其主要原理是遍歷所有集合，然后將文檔一條條讀出來，支持并發(fā)dump多個集合，并且支持歸檔和壓縮，可以輸出到一個文件(或標準輸出)(對原理感興趣可以參見我之前寫的兩篇文章Mongodump的archive(歸檔)模式原理解析以及Mongorestore的archive(歸檔)模式恢復原理解析)。同樣，mongorestore則是連上一個正在服務的mongod節(jié)點進行邏輯恢復。其主要原理是將備份出來的數(shù)據(jù)再一條條寫回到數(shù)據(jù)庫中。
對性能的影響
mongodump執(zhí)行過程由于會遍歷所有數(shù)據(jù)，因此會對MongoDB性能有影響，***在備節(jié)點執(zhí)行(***是hidden，需檢查備節(jié)點數(shù)據(jù)同步是否正常)。
獲取一致的數(shù)據(jù)快照
在mongodump執(zhí)行過程中由于數(shù)據(jù)庫還有新的修改，直接運行dump出來的結(jié)果不是一個一致的快照，需要使用一個『–oplog』的選項來將這個過程中的oplog也一塊dump下來(使用mongorestore進行恢復時對應要使用–oplogReplay選項對oplog進行重放)。而由于MongoDB的oplog是一個固定大小的特殊集合，當oplog集合達到配置的大小時舊的oplog會被滾掉以為新的oplog騰出空間。在使用『–oplog』選項進行dump時，mongodump會在dump集合數(shù)據(jù)前獲取當時***的oplog時間點，并在集合數(shù)據(jù)dump完畢之后再次檢查這個時間點的oplog是否還在，如果dump過程很長，oplog空間又不夠，oplog被滾掉就會dump失敗。因此在dump前***檢查一下oplog的配置大小以及目前oplog的增長情況(可結(jié)合業(yè)務寫入量及oplog平均大小進行粗略估計)，確保dump不會失敗。目前我們阿里云MongoDB服務針對oplog做了彈性擴縮容的優(yōu)化，能夠確保在邏輯備份過程中oplog不被滾掉，一定能夠備份成功。
索引的備份和恢復
對于集合數(shù)據(jù)，mongodump出來的結(jié)果是一個個bson文件。而對于集合的索引，則是描述在一個metadata的json文件里，里面還包含創(chuàng)建集合時所使用的選項。在使用mongorestore進行恢復時，會在集合數(shù)據(jù)恢復完畢之后進行對應的索引創(chuàng)建。
全量物理備份/恢復
對于數(shù)據(jù)量很大的場景，如果使用mongodump/mongorestore進行備份和恢復，需要的時間可能會很長。對于備份來說，最主要的問題就是備份所需時間越長，oplog被滾掉的幾率就越大，備份失敗的幾率也就越大。而對于恢復來說，由于恢復過程還涉及到索引的創(chuàng)建，如果除了數(shù)據(jù)量大，還有很多索引，所需花費的時間就更長了。遇到像爐石這種數(shù)據(jù)災難，恢復時間當然是越短越好，畢竟在游戲行業(yè)分分鐘的流水都很可觀。這時候就需要物理備份出場了，物理備份，顧名思義就是通過物理拷貝數(shù)據(jù)文件實現(xiàn)備份。在恢復時可以直接使用物理備份拷貝出來的數(shù)據(jù)文件，直接啟動mongod。物理備份***的好處是速度快，恢復時也不需要再建索引。
實施方法
物理備份通過拷貝數(shù)據(jù)文件來實現(xiàn)，這要求所有被拷貝的數(shù)據(jù)文件必須是一個一致的數(shù)據(jù)快照。因此物理備份的實施方法和MongoDB采用的存儲引擎有關(guān)，并且，根據(jù)是否配置MongoDB打開了Journal，在實施的細節(jié)上會有一些不同，具體可參考官方文檔。不管使用何種存儲引擎，在3.2版本之后，都可以用以下方法實現(xiàn)物理備份：
通過mongoshell執(zhí)行以下命令以確保所有的寫操作都flush到磁盤并禁止新的寫入：
- db.fsyncLock();
利用底層文件系統(tǒng)層或邏輯卷的快照功能對MongoDB的數(shù)據(jù)目錄做快照，或直接通過cp、scp、tar等命令拷貝數(shù)據(jù)目錄。
還是在剛才的mongoshell上(這里需要保證和剛剛是同一個連接)，執(zhí)行以下命令以重新允許新的寫入：
- db.fsyncUnLock();
由于執(zhí)行db.fsyncLock()會加數(shù)據(jù)庫的全局寫鎖，這時數(shù)據(jù)庫會處于一個不可訪問的狀態(tài)，因此物理備份***也在備節(jié)點上執(zhí)行(***是hidden，注意同樣需要確保物理備份完成之后節(jié)點的oplog能追上主節(jié)點)。目前我們阿里云MongoDB團隊已經(jīng)研發(fā)出了無需停寫服務的物理熱備份手段，相信很快就可以讓大家用上，盡請期待!
增量備份
MongoDB的增量備份可以通過持續(xù)抓取oplog來實現(xiàn)，這個目前沒有現(xiàn)成的工具可以利用，需要自己代碼實現(xiàn)。抓取oplog主要的難題也和使用mongodump進行全量備份一樣，需確保要抓取的oplog不被滾掉。目前我們阿里云MongoDB服務實現(xiàn)了自動增量備份的功能，結(jié)合全量備份可以實現(xiàn)任意時間點恢復功能。
Sharding的備份/恢復
爐石是不分服的，因此它后面也有可能是使用分布式數(shù)據(jù)庫。對于分布式數(shù)據(jù)庫來說，備份和恢復比單機數(shù)據(jù)庫更加復雜。分布式數(shù)據(jù)庫包含多個節(jié)點，并且通常包含不同角色的節(jié)點。以MongoDB的Sharding集群為例，它包含一個保存元數(shù)據(jù)的config server以及若干個保存數(shù)據(jù)的shard。其中最主要的元數(shù)據(jù)就是數(shù)據(jù)在shard之間的分布情況。對于多個節(jié)點的備份，其中一個難題是保證所有節(jié)點備份的數(shù)據(jù)是同一個時間點的，常規(guī)采用的手段是停止外部寫入后進行備份，這在互聯(lián)網(wǎng)服務中顯然不可接受。退而求其次，可以在停止接受同步的備節(jié)點上進行備份，這樣可以得到一個時間大致接近的備份。另外一個難題是各數(shù)據(jù)節(jié)點之間通常存在數(shù)據(jù)遷移，而數(shù)據(jù)遷移就涉及到起碼2個以上數(shù)據(jù)節(jié)點的數(shù)據(jù)修改以及元數(shù)據(jù)節(jié)點的數(shù)據(jù)修改，如果在備份過程中發(fā)生數(shù)據(jù)遷移，很難保證備份出來的數(shù)據(jù)和元數(shù)據(jù)是一個一致的狀態(tài)。因此通常在備份過程中需要關(guān)閉數(shù)據(jù)遷移。MongoDB官方的文檔指導步驟就是采用這個思路，先關(guān)閉負責數(shù)據(jù)遷移的balancer，然后依次在config server和各個shard的備節(jié)點上進行備份。關(guān)閉數(shù)據(jù)遷移***的問題是關(guān)閉期間集群無法實現(xiàn)數(shù)據(jù)均衡，除了會影響集群的訪問性能外，還造成資源的浪費，這在數(shù)據(jù)量較大，所需備份時間較長時可能造成比較大的影響。
針對這兩大難題，我們阿里云MongoDB團隊研發(fā)了不需要停外部寫，并且無需關(guān)數(shù)據(jù)遷移的Sharding備份手段，能夠?qū)崿F(xiàn)『任意』時間點恢復，這個功能將伴隨著即將推出的Sharding形態(tài)一起推出，盡情期待!
阿里云MongoDB備份服務
阿里云MongoDB服務提供自動備份/恢復功能，默認每天為數(shù)據(jù)進行全量備份，并且自動抓取oplog進行增量備份。用戶可以在控制臺自定義備份策略以及進行恢復。
恢復時可以選擇某一個備份集或某一個時間點克隆出一個新的實例，可以在新實例上進行數(shù)據(jù)校驗，等校驗沒問題后切換到新實例。此外，全量備份的數(shù)據(jù)還提供下載功能，用戶也可以選擇下載備份集到本地后恢復到一個臨時實例進行數(shù)據(jù)校驗。
總結(jié)
說了這么多，大家應該對MongoDB的備份/恢復手段有了一個大概的認識。如果要圖省心，還是建議直接使用阿里云MongoDB服務，我們有自動化的備份/恢復服務，靈活的備份策略，只需點點鼠標就能用上任意時間點恢復、物理熱備份、Sharding備份/恢復這些黑科技，從此不再為數(shù)據(jù)庫容災發(fā)愁，業(yè)務你們做，鍋有我們來背，還等什么呢，快來試用吧!
作者：鄭涔，花名明儼，阿里云數(shù)據(jù)庫組技術(shù)專家，主要關(guān)注分布式存儲、Nosql數(shù)據(jù)庫等技術(shù)領域，目前主要參與MongoDB云數(shù)據(jù)庫的研發(fā)，致力于讓開發(fā)者用上***的MongoDB云服務。
文章標題：從爐石傳說數(shù)據(jù)庫故障談談MongoDB的數(shù)據(jù)庫備份和恢復手段
文章路徑：http://m.5511xx.com/article/cdgcjio.html
