MongoDB的資料庫如何備份和恢復?

2021-09-23 18:02:20 字數 3530 閱讀 5721

mongodb資料庫如何備份?恢復mongodb資料庫應如何操作?最近資料庫多災多難,這些問題也成為開發者關注的重點。2023年12月爆出mongodb資料庫安全問題(見mongodb

黑客贖金事件解讀及防範

)。2023年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備份/恢復,從此不再為資料庫容災發愁。

MongoDB的資料庫如何備份和恢復?

摘要 mongodb資料庫如何備份?恢復mongodb資料庫應如何操作?最近資料庫多災多難,這些問題也成為開發者關注的重點。2016年12月爆出mongodb資料庫安全問題 見mongodb黑客贖金事件解讀及防範 mongodb資料庫如何備份?恢復mongodb資料庫應如何操作?最近資料庫多災多難,...

mongodb資料庫備份恢復

mongodb資料檔案備份與恢復 備份與恢復資料對於管理任何資料儲存系統來說都是非常重要的。1 冷備份與恢復 建立資料檔案的副本 前提是要停止mongodb伺服器 也就是直接copy www.2cto.com mongodb將所有資料都儲存在資料目錄下,預設是 data db windows下是c ...

備份mongodb資料庫(認證)

建乙個記事本,改為以bat結尾,新增到window計畫任務中 echo off title mongodb自動備份指令碼 echo 開始執行備份.生成資料夾格式 年 月 日 set pathdir date 0,4 date 5,2 date 8,2 定義備份檔案路徑 set backpath d ...