數據庫的自我修煉——阿里雲MongoDB備份恢復功能說明和原理介紹

本次直播視頻精彩回顧，戳這裏！

 

直播涉及到的PPT，戳這裏！

 

演講嘉賓簡介：

 

鄭涔（花名：明儼） 阿里雲技術專家，2011年加入阿里，曾參與TFS、Tengine研發，目前主要參與阿里雲MongoDB雲數據庫服務研發，主要關注分佈式存儲、數據庫等領域。

 

本篇文章來自於阿里雲技術專家鄭涔（明儼）在2018年《Redis、MongoDB、HBase大咖直播大講堂》技術直播峯會中的分享，該分享總體由四個部分構成：

 

一、MongoDB備份恢復

 

二、阿里雲MongoDB備份恢復

 

三、阿里雲MongoDB Sharding備份恢復

 

四、阿里雲MongoDB物理熱備份恢復

 

初來乍到——MongoDB備份恢復

 

MongoDB備份恢復在備份方法上整體來講分爲兩部分：邏輯備份和物理備份。

 

 

邏輯備份就是經過mongodump和mongorestore兩個工具在數據庫層將MongoDB的數據進行導出和導入。物理備份的做用更接近底層一些，例如做用在文件系統上，經過cp和tar文件系統工具，將MongoDB的物理文件拷貝走進行備份。物理備份還有一種方式是經過邏輯卷或者塊設備更爲底層的部分進行備份，例如配置一個邏輯卷採用lvm snapshot的方法去作磁盤的快照，或者利用像阿里雲的ECS雲服務器執行雲盤的快照功能，從而實現物理備份。

 

 

MongoDB全量邏輯備份恢復是經過mongodump和mongorestore兩個工具來實現的，這兩個工具不只能夠做用在正在運行的MongoDB上，也能夠做用在Sharding的mongos上，把整個數據庫的數據進行導入導出。全量邏輯備份恢復能夠輸出爲兩種格式：第一種爲BSON格式，以這種方式導出以後能夠看到本地磁盤上會有不少目錄，每個數據庫都會有各自的BSON格式的數據；第二種爲歸檔的格式，即把全部數據庫的數據輸出成一個文件，能夠方便地實現流式備份和恢復。

 

全量邏輯備份的基本機制是經過數據庫層的一些結構來實現的，在當本的過程當中經過數據庫find的方法，將數據庫中的數據所有查詢出來，若是數據爲索引時，導出的只是一些元數據，例如索引建在哪一個字段上、什麼類型的索引、索引有哪些選項這些元數據，並無把索引的數據自己導出來，在恢復時經過insert方法從新將數據插回到數據庫當中。在恢復的過程當中須要重建索引，若是索引的數據量很是大，重建索引的過程將花費很長的時間，成爲了全量邏輯備份比較大的問題。

 

全量邏輯備份恢復的一大優勢，即備份和恢復單庫單表的能力，方便於某些場景的應用，例如緊急狀態下須要恢復某一數據庫的某一個表，此時不須要下載整個全量的數據備份，只需單獨把想要恢復的表進行恢復便可。

 

全量邏輯備份經過數據庫接口訪問數據庫，若是數據庫配置一個認證須要帳號和密碼進行訪問時會有一些權限的要求，能夠經過MongoDB內置的backup和restore兩個角色進行備份和恢復。

 

此外，全量邏輯備份能夠指定進行gzip壓縮，從而減小數據備份的大小，節省存儲成本。

 

在MongoDB全量邏輯備份過程當中數據庫能夠接受外部正常的讀寫，使用oplog選項抓取備份過程當中的修改，恢復時使用oplogReplay選項，此時須要較高的額外權限，從而獲取一致的備份，確保數據備份的過程當中，對數據的修改也會進行備份。

 

 

MongoDB全量物理備份恢復經過某些手段將物理文件拷貝走進行備份，其中MongoDB能夠支持多個存儲引擎，物理文件與存儲引擎的存儲佈局相關，因此物理備份恢復沒法作到跨存儲引擎的備份恢復，例如使用WiredTiger的存儲引擎備份的數據只能恢復成WiredTiger，不能恢復成其餘的存儲引擎。另外物理備份有一個很大的好處是，因爲備份時將全部的域塊進行備份，在恢復的過程當中不須要重建索引，只須要將備份數據下載下來，提起進程便可使用，相對全量邏輯備份更爲高效。

 

然而全量物理備份的不足之處在於，它不具有備份和恢復單庫單表的能力，文件之間相互關聯，沒法將某一個數據庫的單獨文件提取恢復出來。

 

全量物理備份方法一般能夠分爲兩大類：第一類是經過一些系統組件的snapshot快照功能來實現備份，對系統組件有些依賴，在單盤多租戶的狀況下，沒法作到對塊盤上每個MongoDB實例單獨進行備份，依賴於配置MongoDB的Journal實現宕機恢復，從而達到一致備份；第二類是使用文件拷貝簡單的方式經過文件系統進行物理備份，能夠作到目錄級的拷貝，支持單盤多租戶的數據拷貝，在文件拷貝開始以前須要執行db.fsyncLock的命令，即對MongoDB的全局加一個寫鎖，在整個備份的過程當中數據庫沒法提供服務，物理文件拷貝完畢執行db.fsynUnclock解鎖命令，間接達到一致備份的效果。

 

 

整體上來看，在備份效率上，邏輯備份不如物理備份。邏輯備份經過數據庫接口讀取數據，當邏輯備份數據量很小、條目不少時，效率會很低，物理備份時物理文件通常會通過文件壓縮，拷貝的數據相對來講比較少，同時物理備份較充分地使用系統資源，效率會較高。在恢復效率上，邏輯備份也低於物理備份。邏輯備份須要導入數據和重建索引，而物理備份直接啓動進程便可。在備份影響上，備份影響主要指在備份的過程當中是否對一些正常的業務訪問產生影響，因爲邏輯備份經過數據庫接口讀取數據，它將直接與業務爭搶數據庫資源，而物理備份間接爭搶系統的資源，相對來講備份影響比較小。在備份集的大小上，因爲邏輯備份沒有備份索引數據，通常比原數據庫小或相同，而物理備份與原數據庫是如出一轍的。在兼容性上，邏輯備份優於物理備份，物理備份與存儲引擎相關，沒法作到跨存儲引擎的備份恢復，而邏輯備份兼容絕大部分版本。同時，物理備份的成功率比邏輯備份高不少，在某些場景邏輯備份沒法進行恢復。

 

 

在MongoDB副本集有oplog進行主備同步，增量備份就是採集oplog並進行存儲，全量備份加增量備份就能夠實現任意時間點的備份。

 

厚德載物——阿里雲MongoDB備份恢復

 

阿里雲MongoDB備份恢復主要分爲四大塊：備份、恢復、備份存儲和備份有效性驗證。

 

 

備份當中能夠定製一些備份策略，爲用戶的MongoDB作一些自動備份，用戶也能夠在控制檯進行手動備份，同時用戶能夠指定一個備份週期和保留時間對備份進行安排。恢復策略中用戶能夠選擇恢復時覆蓋原來的實例或者克隆一個新的實例，也能夠指定恢復的力度，選擇恢復到全量的備份集或者恢復到指定的時間點。備份存儲中，將數據存儲在阿里雲OSS上具備10個9的可靠性。備份有效性驗證中，按期對MongoDB實例的備份作一些有效性的驗證，避免恢復備份時發現備份出現問題，確保備份能夠進行恢復。

 

如下爲阿里雲MongoDB控制檯的兩個主要界面：

 

 

上圖爲備份列表界面，能夠看到備份的一些狀況，包括備份的完成時間、是否爲自動備份、手動備份等。用戶能夠點擊右上角的備份實例進行手動備份，能夠下載備份、根據備份建立實例或者指定一個時間點新建實例、克隆實例。

 

 

上圖爲備份設置界面，用戶能夠制定一些備份策略，包括備份的保留天數、備份的週期等。

 

精益求精——阿里雲MongoDB Sharding備份恢復

 

 

MongoDB Sharding架構主要由三大組件構成：藍色部分爲路由節點mongos，它是無狀態的、沒有存儲數據的，不須要進行備份；綠色部分爲Shard集羣，用於存儲用戶分片的數據，經過副本集的方式實現高可用，須要進行數據備份；黃色部分爲Config Servers，主要存放集羣當中的元數據，做爲副本集一樣須要進行備份。

 

面對MongoDB Sharding出現的問題，阿里雲是如何進行有效解決的呢？

 

 

第一個廣泛的問題是關於集羣多個節點在外部修改狀況下如何取得一致備份。在一個集羣當中的多個節點和每個節點的容量是不一樣的，致使節點備份的耗時不一樣，當對應用進行寫入時，因爲每一個節點備份結束的時間不一樣，有些節點的備份會多包含一些新寫入的數據，其中備份結束的時間點很難進行肯定。

 

 

針對問題一，阿里雲採用全量備份加增量備份能夠作到各節點備份恢復至同一時間點，在備份結束比較早的節點能夠多抓取一些oplog，備份結束比較晚的節點能夠少抓取一些oplog，從而保證各自節點的備份加oplog可以對應到同一個時間點。

 

 

第二個備份問題是關於內部數據的修改，在集羣內部一般會有數據的遷移，上圖展現了MongoDB Sharding內部數據的一些表示，在作Sharding時一般須要指定一個Shard Key即分片的片鍵，接下來的數據將會按照Shard Key的大小範圍進行分佈，例如選擇使用哈希分片，按照Shard Key哈希以後的結果做爲分佈。Chunk是Shard Key一部分範圍所對應值的集合，例如上圖左側分爲4個Chunk，分別對應Shard Key的不一樣取值範圍。上圖右側Chunk做爲一個基礎的單元在不一樣的Shard之間進行分佈，config server存放着元數據。

 

 

因爲對集羣進行擴容的須要，增長或刪除Shard須要MongoDB Sharding進行數據遷移，同時數據分佈不均時也會自發地進行數據遷移，而MongoDB能夠決定是否採用數據遷移。上圖右側即爲Chunk遷移的基本過程。

 

 

如上圖所示，兩個Shard上的Chunk不均衡，Chunk1須要從Shard1遷移到Shard2上，當全部的節點備份結束時，Chunk1的遷移可能尚未結束，同時config server上仍是原來的數據分佈，此時Shard1仍存在三個Chunk，而Shard2存儲部分Chunk1，因爲數據恢復是以config server爲基準，決定去哪裏訪問Chunk數據，因此會認爲Shard2拷貝了多餘的Chunk1數據產生數據重複。另一種狀況，備份結束後config server已經更新了路由信息，確認Chunk1已經在Shard2上，可是Shard2中的Chunk2數據尚未徹底拷貝完畢，數據恢復時會發現會有一部分的Chunk2數據丟失。綜上所述，Chunk遷移可能致使數據的重複與丟失問題。

 

 

針對問題二，阿里雲會對內部的Chunk遷移進行分析，而後對恢復的時間點進行限制避開有數據遷移的時間段，只有這個時間點沒有數據遷移才容許恢復至這個時間點。

 

 

爲了解決以上問題，用戶在MongDB Sharding備份時能夠配置一個遷移的時間段，即用戶能夠根據業務訪問行爲指定遷移在哪段時間進行，從而保證遷移在預期時間段內進行，其它時間段能夠進行備份恢復。能夠經過上圖中的三段代碼配置遷移的時間點。

 

 

上圖爲阿里雲MongoDB Sharding備份恢復的控制檯，與備份列表界面相比多了選擇Shard的功能，能夠選擇某一個Shard查看備份狀況。

 

虛懷若谷——阿里雲MongoDB物理熱備份恢復

 

 

上文提到，經過文件拷貝作物理備份時，備份過程全程加全局寫鎖，不是熱備份，在這段期間MongoDB是沒法正常訪問的。事實上WiredTiger存儲引擎支持熱備份，支持在備份過程當中不停服務，爲何還要在MongoDB上加全局寫鎖呢？其一MongoDB會在內存當中維護一些數據，須要經過fsyncLock把一些元數據刷到磁盤當中；其二WiredTiger的熱備份有個問題，若是在備份的過程中有寫入，磁盤的空間增加得比較快。

 

 

阿里雲針對以上問題對MongoDB和WiredTiger進行了改造，抽象了三個階段的備份過程，在備份以前加入了預備份步驟，在備份以後加入了post-backup動做，而且只須要在預備份階段加入全局寫鎖便可。同時阿里雲改進了WiredTiger的熱備份機制，解決了熱備份過程當中磁盤增加太快的問題。阿里雲MongoDB物理熱備份的方法在去年6月份就已經上線，目前的新實例也默認使用熱備份方式。

閱讀原文http://click.aliyun.com/m/41118/