任何數(shù)據(jù)庫都離不開日常的備份與恢復，這二者是數(shù)據(jù)庫安全的前提，MongoDB的備份與恢復方法一般而言都采用自帶的工具來進行。

     在開始講述備份之前，需要首先了解兩個概念，一個是恢復點目標、一個叫恢復時間目標,下面我們分別來看：

• 恢復點目標：

（也叫RPO，recovery point objective）

也就是數(shù)據(jù)可以恢復到哪個時間點，可以承受多少損失。

• 恢復時間目標：

(也叫RTO，recover time objective)，在發(fā)生故障的時候，數(shù)據(jù)庫可以承受多長時間宕機。

有了這兩個概念，就可以理解不同備份恢復方法可以滿足的RPO和RTO是多少了。

來看備份工具：

Mongodump工具

在MongoDB中，mongodump工具通常用來做備份使用。它有如下特點：

1、可以對mongos和mongod進行操作

2、備份的是數(shù)據(jù)和數(shù)據(jù)結(jié)構(gòu)，會以bson數(shù)據(jù)格式存儲

3、不會備份索引，只會備份索引的元數(shù)據(jù)，只有在恢復的時候才會重建索引。

4、備份的過程中，mongodump會批量的將數(shù)據(jù)加載到內(nèi)存中，該方法在數(shù)據(jù)量比較大的時候，會持續(xù)占用內(nèi)存資源，會增加IO負載壓力。

5、可以備份整個數(shù)據(jù)庫、整個集合、部分集合內(nèi)容

該工具的缺點：

1、僅僅適合備份小型的、或者單一數(shù)據(jù)庫的備份

2、數(shù)據(jù)量大的時候，備份時間較長

關于Mongodump的命令使用方法，大家可以mongodump --help去查看，常用選項如下：

-p，--port：端口

-h，--host：IP地址

-d，--db：數(shù)據(jù)庫

-c，--collection：備份的集合名稱

-q，--query：備份數(shù)據(jù)的條件表達式

-o，--out：備份文件的存放位置

-u，--username：用戶名

-p，--password：密碼

--authenticationDataBase：認證數(shù)據(jù)庫

具體的使用方法，下面有例子。

Mongorestore工具

   數(shù)據(jù)備份和數(shù)據(jù)恢復二者是不可分割的，因為數(shù)據(jù)的備份，本質(zhì)上還是為了恢復準備的，如果備份的數(shù)據(jù)不能恢復，那么備份也就失去了意義。

    在MongoDB中，Mongorestore這個工具是用來做數(shù)據(jù)恢復的，數(shù)據(jù)恢復命令的常用參數(shù)如下：

與mongodump重復的部分不再贅述

-p，--port

-h，--host

-d，--db

-c，--collection

--dir：恢復文件存放的位置，如果指定了數(shù)據(jù)庫文件夾或者集合文件，則只恢復當前數(shù)據(jù)庫或者當前集合，如果沒有指定，則恢復當前目錄下所有備份數(shù)據(jù)。

--drop：恢復前會刪除已有的數(shù)據(jù)庫

-u，--user

-p，--password

--authenticationDatabase

下面來看樣例：

數(shù)據(jù)備份舉例

備份所有數(shù)據(jù)庫
mongodump --port=27017 -h 127.0.0.1 -o /data/mongodb_backup -u root -p 123456 
2020-11-23T23:40:41.599+0800 writing admin.system.users to 
2020-11-23T23:40:41.626+0800 done dumping admin.system.users (3 documents)
2020-11-23T23:40:41.626+0800 writing admin.system.roles to 
2020-11-23T23:40:41.651+0800 done dumping admin.system.roles (1 document)
2020-11-23T23:40:41.651+0800 writing admin.system.version to 
2020-11-23T23:40:41.680+0800 done dumping admin.system.version (2 documents)
2020-11-23T23:40:41.680+0800 writing test.yeyz to 
2020-11-23T23:40:41.680+0800 writing yeyz.test to 
2020-11-23T23:40:41.726+0800 done dumping yeyz.test (2 documents)
2020-11-23T23:40:41.727+0800 done dumping test.yeyz (3 documents)

備份yeyz這一個數(shù)據(jù)庫
[root@VM-0-14-centos ~]# mongodump -d yeyz --port=27017 -h 127.0.0.1 -o /data/mongodb_backup -u root -p 123456 --authenticationDatabase admin   
2020-11-23T23:41:58.991+0800 writing yeyz.test to 
2020-11-23T23:41:59.050+0800 done dumping yeyz.test (2 documents)

備份yeyz數(shù)據(jù)庫中的test集合中的name=ccc的記錄
[root@VM-0-14-centos ~]# mongodump -d yeyz -c test -q '{name:{$eq:"ccc"}}' --port=27017 -h 127.0.0.1 -o /data/mongodb_backup -u root -p 123456 --authenticationDatabase admin
2020-11-23T23:43:24.473+0800 writing yeyz.test to 
2020-11-23T23:43:24.501+0800 done dumping yeyz.test (1 document)

數(shù)據(jù)恢復舉例

恢復前
> use yeyz
switched to db yeyz
> show tables;
test
> db.test.find()
{ "_id" : ObjectId("5fa7eae2515b814f18f2d474"), "name" : "ccc" }
{ "_id" : ObjectId("5fa7f00e523d80402cdfa326"), "name" : "bbb" }

恢復后
> show tables;
test
test_recover
> db.test_recover.find()
{ "_id" : ObjectId("5fa7eae2515b814f18f2d474"), "name" : "ccc" }

我們成功的將上面的yeyz數(shù)據(jù)庫中的test集合中的name=ccc的記錄恢復到了test_recover這個集合當中。

物理備份

    物理備份的概念大家應該都理解，常用的方法是復制物理硬盤上的數(shù)據(jù)庫文件。

    想要保證復制的物理文件和真實的數(shù)據(jù)庫文件一致，需要保證當前數(shù)據(jù)庫沒有寫入。如果數(shù)據(jù)庫有寫入，則復制的數(shù)據(jù)是不準確的。所以，物理復制必須在MongoDB實例停機狀態(tài)或者鎖定狀態(tài)下進行。一般來講，在MongoDB集群中，我們會使用鎖定從庫的辦法來進行備份。

    通常情況下，使用：

db.fsyncLock()  鎖定從數(shù)據(jù)庫。

db.fsyncUnlock（） 解鎖數(shù)據(jù)庫

    鎖定從節(jié)點的數(shù)據(jù)庫之后，在從節(jié)點上使用物理文件拷貝的方式進行備份即可。

    備份完成即可解鎖數(shù)據(jù)庫。

最后，數(shù)據(jù)備份的時候，如果有寫入，那么備份的數(shù)據(jù)是否會不準確？例如下面這樣：

如果我們的備份進度處在中間位置，即：

    A庫備份完成的時候，B庫沒有開始備份

此時分別寫入A庫和B庫兩個文檔，則最終的備份結(jié)果中，A庫的數(shù)據(jù)沒有新增的數(shù)據(jù)，B庫的數(shù)據(jù)有新增的數(shù)據(jù)，就會產(chǎn)生數(shù)據(jù)的不一致。為了解決這個問題，備份一般都使用鎖定數(shù)據(jù)庫或者停止實例的方法來解決。

    在MongoDB中，可以在從庫上進行鎖定或者停止實例的備份操作，不建議在線上環(huán)境使用MongoDB單庫，因為這種情況，備份恢復將會成為一個瓶頸問題。

以上就是MongoDB的備份與恢復的詳細內(nèi)容，更多關于MongoDB 備份與恢復的資料請關注腳本之家其它相關文章！