MongoDB的備份與恢復

時間  2019-12-07
標籤 mongodb 備份 恢復 欄目 MongoDB 简体版
原文   原文鏈接

1.1 MongoDB的經常使用命令

mongoexport / mongoimport
mongodump  / mongorestore

　　   有以上兩組命令在備份與恢復中進行使用。html

1.1.1 導出工具mongoexport

Mongodb中的mongoexport工具能夠把一個collection導出成JSON格式或CSV格式的文件。能夠經過參數指定導出的數據項，也能夠根據指定的條件導出數據。mysql

   該命令的參數以下：sql

參數mongodb

參數說明shell

-h數據庫

指明數據庫宿主機的IPjson

-u性能優化

指明數據庫的用戶名服務器

-p數據結構

指明數據庫的密碼

-d

指明數據庫的名字

-c

指明collection的名字

-f

指明要導出那些列

-o

指明到要導出的文件名

-q

指明導出數據的過濾條件

--type

指定文件類型

--authenticationDatabase

驗證數據的名稱

mongoexport備份實踐

備份app庫下的vast集合

mongoexport -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d app -c vast -o /home/mongod/backup/vasts.dat

注：備份文件的名字能夠自定義，默認導出了JSON格式的數據。

導出CSV格式的數據

mongoexport -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d app -c vast --type=csv -f id,name -o /home/mongod/backup/vast_csv.dat

1.1.2 導入工具mongoimport

　　Mongodb中的mongoimport工具能夠把一個特定格式文件中的內容導入到指定的collection中。該工具能夠導入JSON格式數據，也能夠導入CSV格式數據。

該命令的參數以下：   

參數

參數說明

-h

指明數據庫宿主機的IP

-u

指明數據庫的用戶名

-p

指明數據庫的密碼

-d

指明數據庫的名字

-c

指明collection的名字

-f

指明要導出那些列

-o

指明到要導出的文件名

-q

指明導出數據的過濾條件

--drop

插入以前先刪除原有的

--headerline

指明第一行是列名，不須要導入。

-j

同時運行的插入操做數（默認爲1），並行

--authenticationDatabase

驗證數據的名稱

mongoimport恢復實踐

將以前恢復的數據導入

mongoimport -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d app -c vast  --drop /home/mongod/backup/vasts.dat

將以前恢復的CSV格式數據導入

mongoimport -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d app -c vast --type=csv --headerline --file vast_csv.dat

1.1.3 【實驗】mysql數據遷移至mongodb數據庫

　　　　mysql相關的參考文檔：http://www.cnblogs.com/clsn/category/1131345.html

將mysql數據庫中的mysql下的user表導出。

select user,host,password from mysql.user
into outfile '/tmp/user.csv'
fields terminated by ','
optionally enclosed by '"'
escaped by '"' 
lines terminated by '\r\n';

命令說明：

into outfile '/tmp/user.csv'  ------導出文件位置  
fields terminated by ','　　   ------字段間以,號分隔
optionally enclosed by '"'　  ------字段用"號括起
escaped by '"'   　　　　　   　------字段中使用的轉義符爲"
lines terminated by '\r\n'; 　------行以\r\n結束

查看導出內容

[mongod@MongoDB tmp]$ cat user.csv 
"root","localhost",""
"root","db02",""
"root","127.0.0.1",""
"root","::1",""
"","localhost",""
"","db02",""
"repl","10.0.0.%","*23AE809DDACAF96AF0FD78ED04B6A265E05AA257"
"mha","10.0.0.%","*F4C9AC49A736981AE2739FC2F4A1FD92B4F07929"

在mongodb中導入數據

mongoimport -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d app -c user -f user,host,password  --type=csv --file /tmp/user.csv

   查看導入的內容

[root@MongoDB tmp]# mongo --port 27017 
MongoDB shell version: 3.2.8
connecting to: 127.0.0.1:27017/test
> use app 
switched to db app
> db.user.find()
{ "_id" : ObjectId("5a53206b3b42ae4683180009"), "user" : "root\tlocalhost" }
{ "_id" : ObjectId("5a53206b3b42ae468318000a"), "user" : "root\tdb02" }
{ "_id" : ObjectId("5a53206b3b42ae468318000b"), "user" : "root\t127.0.0.1" }
{ "_id" : ObjectId("5a53206b3b42ae468318000c"), "user" : "root\t::1" }
{ "_id" : ObjectId("5a53206b3b42ae468318000d"), "user" : "localhost" }
{ "_id" : ObjectId("5a53206b3b42ae468318000e"), "user" : "db02" }
{ "_id" : ObjectId("5a53206b3b42ae468318000f"), "user" : "repl\t10.0.0.%\t*23AE809DDACAF96AF0FD78ED04B6A265E05AA257" }
{ "_id" : ObjectId("5a53206b3b42ae4683180010"), "user" : "mha\t10.0.0.%\t*F4C9AC49A736981AE2739FC2F4A1FD92B4F07929" }

　　   到此數據遷移完成。

1.2 mongodump/mongorestore實踐

1.2.1 mongodump備份工具

　　mongodump的參數與mongoexport的參數基本一致 

參數

參數說明

-h

指明數據庫宿主機的IP

-u

指明數據庫的用戶名

-p

指明數據庫的密碼

-d

指明數據庫的名字

-c

指明collection的名字

-o

指明到要導出的文件名

-q

指明導出數據的過濾條件

--authenticationDatabase

驗證數據的名稱

--gzip

備份時壓縮

--oplog

use oplog for taking a point-in-time snapshot

mongodump參數實踐

全庫備份

mongodump -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -o /home/mongod/backup/full

備份test庫

mongodump -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d test -o /home/mongod/backup/

備份test庫下的vast集合

mongodump -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d test -c vast -o /home/mongod/backup/

壓縮備份庫

mongodump -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d test -o /home/mongod/backup/ --gzip

壓縮備份單表

mongodump -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin  -d test -c vast -o /home/mongod/backup/ --gzip

1.2.2 mongorestore恢復實踐

　　mongorestore與mongoimport參數相似 

參數

參數說明

-h

指明數據庫宿主機的IP

-u

指明數據庫的用戶名

-p

指明數據庫的密碼

-d

指明數據庫的名字

-c

指明collection的名字

-o

指明到要導出的文件名

-q

指明導出數據的過濾條件

--authenticationDatabase

驗證數據的名稱

--gzip

備份時壓縮

--oplog

use oplog for taking a point-in-time snapshot

--drop

恢復的時候把以前的集合drop掉

全庫備份中恢復單庫（基於以前的全庫備份）

mongorestore -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d test --drop  /home/mongod/backup/full/test/

恢復test庫

mongorestore -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d test /home/mongod/backup/test/

恢復test庫下的vast集合

mongorestore -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d test -c vast /home/mongod/backup/test/vast.bson

--drop參數實踐恢復

# 恢復單庫
mongorestore -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d test --drop /home/mongod/backup/test/
# 恢復單表
mongorestore -h 10.0.0.152:27017 -uroot -proot --authenticationDatabase admin -d test -c vast --drop /home/mongod/backup/test/vast.bson

1.2.3 mongoexport/mongoimport與mongodump/mongorestore的對比

 

  1. mongoexport/mongoimport導入/導出的是JSON格式，而mongodump/mongorestore導入/導出的是BSON格式。
  2. JSON可讀性強但體積較大，BSON則是二進制文件，體積小但對人類幾乎沒有可讀性。
  3. 在一些mongodb版本之間，BSON格式可能會隨版本不一樣而有所不一樣，因此不一樣版本之間用mongodump/mongorestore可能不會成功，具體要看版本之間的兼容性。當沒法使用BSON進行跨版本的數據遷移的時候，使用JSON格式即mongoexport/mongoimport是一個可選項。跨版本的mongodump/mongorestore並不推薦，實在要作請先檢查文檔看兩個版本是否兼容（大部分時候是的）。
  4. JSON雖然具備較好的跨版本通用性，但其只保留了數據部分，不保留索引，帳戶等其餘基礎信息。使用時應該注意。

1.3 MongoDB中的oplog

1.3.1 什麼是oplog

　　MongoDB 的Replication是經過一個日誌來存儲寫操做的，這個日誌就叫作oplog。

　　在默認狀況下,oplog分配的是5%的空閒磁盤空間。一般而言,這是一種合理的設置。能夠經過mongod --oplogSize來改變oplog的日誌大小。

　　oplog是capped collection，由於oplog的特色（不能太多把磁盤填滿了，固定大小）須要，MongoDB才發明了capped collection（the oplog is actually the reason capped collections were invented）. 定值大小的集合，oplogSizeMB: 2048，oplog是具備冪等性，執行事後的不會反覆執行。

　　值得注意的是，oplog爲replica set或者master/slave模式專用（standalone模式運行mongodb並不推薦）。

oplog的位置：

oplog在local庫： local。oplog

master/slave 架構下：local.oplog.$main;

 

replica sets 架構下：local.oplog.rs

參數說明

$ mongodump --help
 --oplog use oplog for taking a point-in-time snapshot

　　該參數的主要做用是在導出的同時生成一個oplog.bson文件，存放在你開始進行dump到dump結束之間全部的oplog。

　　oplog 官方說明https://docs.mongodb.com/manual/core/replica-set-oplog/

 

　　簡單地說，在replica set中oplog是一個定容集合（capped collection），它的默認大小是磁盤空間的5%（能夠經過--oplogSizeMB參數修改），位於local庫的db.oplog.rs，有興趣能夠看看裏面到底有些什麼內容。

　　其中記錄的是整個mongod實例一段時間內數據庫的全部變動（插入/更新/刪除）操做。當空間用完時新記錄自動覆蓋最老的記錄。

　　因此從時間軸上看，oplog的覆蓋範圍大概是這樣的：

  

　　其覆蓋範圍被稱做oplog時間窗口。須要注意的是，由於oplog是一個定容集合，因此時間窗口能覆蓋的範圍會由於你單位時間內的更新次數不一樣而變化。想要查看當前的oplog時間窗口預計值.

sh1:PRIMARY> rs.printReplicationInfo()
configured oplog size:   2048MB   <--集合大小
log length start to end: 305451secs (84.85hrs)  <--預計窗口覆蓋時間
oplog first event time:  Thu Jan 04 2018 19:39:05 GMT+0800 (CST)
oplog last event time:   Mon Jan 08 2018 08:29:56 GMT+0800 (CST)
now:                     Mon Jan 08 2018 16:33:25 GMT+0800 (CST)

　　oplog有一個很是重要的特性——冪等性（idempotent）。即對一個數據集合，使用oplog中記錄的操做重放時，不管被重放多少次，其結果會是同樣的。

　　舉例來講，若是oplog中記錄的是一個插入操做，並不會由於你重放了兩次，數據庫中就獲得兩條相同的記錄。這是一個很重要的特性.

1.3.2 oplog.bson做用

與oplog相關的參數

參數

參數說明

--oplogReplay

重放oplog.bson中的操做內容

--oplogLimit

與--oplogReplay一塊兒使用時，能夠限制重放到的時間點

　　首先要明白的一個問題是數據之間互相有依賴性，好比集合A中存放了訂單，集合B中存放了訂單的全部明細，那麼只有一個訂單有完整的明細時纔是正確的狀態。

　　假設在任意一個時間點，A和B集合的數據都是完整對應而且有意義的（對非關係型數據庫要作到這點並不容易，且對於MongoDB來講這樣的數據結構並不是合理。但此處咱們假設這個條件成立），那麼若是A處於時間點x，而B處於x以後的一個時間點y時，能夠想象A和B中的數據極有可能不對應而失去意義。

　　mongodump的進行過程當中並不會把數據庫鎖死以保證整個庫凍結在一個固定的時間點，這在業務上經常是不容許的。因此就有了dump的最終結果中A集合是10點整的狀態，而B集合則是10點零1分的狀態這種狀況。

　　這樣的備份即便恢復回去，能夠想象獲得的結果恐怕意義有限。

　　那麼上面這個oplog.bson的意義就在這裏體現出來了。若是在dump數據的基礎上，再重作一遍oplog中記錄的全部操做，這時的數據就能夠表明dump結束時那個時間點（point-in-time）的數據庫狀態。

1.3.3 【模擬】mongodump使用

首先咱們模擬一個不斷有插入操做的集合foo，

use clsn
for(var i = 0; i < 10000; i++) {
    db.clsn.insert({a: i});
}

　　而後在插入過程當中模擬一次mongodump並指定--oplog。

mongodump -h 10.0.0.152 --port 28021  --oplog  -o /home/mongod/backup/oplog

　　注意：--oplog選項只對全庫導出有效，因此不能指定-d選項。

　　　　   由於整個實例的變動操做都會集中在local庫中的oplog.rs集合中。

根據上面所說，從dump開始的時間系統將記錄全部的oplog到oplog.bson中，因此咱們獲得這些文件：

[mongod@MongoDB ~]$ ll /home/mongod/backup/oplog 
total 8
drwxrwxr-x 2 mongod mongod   4096 Jan  8 16:49 admin
drwxrwxr-x 2 mongod mongod   4096 Jan  8 16:49 clsn
-rw-rw-r-- 1 mongod mongod  77256 Jan  8 16:49 oplog.bson

查看oplog.bson中第一條和最後一條內容

[mongod@MongoDB oplog]$ bsondump oplog.bson  >/tmp/oplog.bson.tmp
[mongod@MongoDB oplog]$ head -1 /tmp/oplog.bson.tmp 
{"ts":{"$timestamp":{"t":1515401553,"i":666}},"t":{"$numberLong":"5"},"h":{"$numberLong":"5737315465472464503"},"v":2,"op":"i","ns":"clsn.clsn1","o":{"_id":{"$oid":"5a533151cc075bd0aa461327"},"a":3153.0}}
[mongod@MongoDB oplog]$ tail -1 /tmp/oplog.bson.tmp 
{"ts":{"$timestamp":{"t":1515401556,"i":34}},"t":{"$numberLong":"5"},"h":{"$numberLong":"-7438621314956315593"},"v":2,"op":"i","ns":"clsn.clsn1","o":{"_id":{"$oid":"5a533154cc075bd0aa4615de"},"a":3848.0}}

　　最終dump出的數據既不是最開始的狀態，也不是最後的狀態，而是中間某個隨機狀態。這正是由於集合不斷變化形成的。

　　使用mongorestore來恢復

[mongod@MongoDB oplog]$ mongorestore -h 10.0.0.152 --port 28021  --oplogReplay  --drop   /home/mongod/backup/oplog
2018-01-08T16:59:18.053+0800    building a list of dbs and collections to restore from /home/mongod/backup/oplog dir
2018-01-08T16:59:18.066+0800    reading metadata for clsn.clsn from /home/mongod/backup/oplog/clsn/clsn.metadata.json
2018-01-08T16:59:18.157+0800    restoring clsn.clsn from /home/mongod/backup/oplog/clsn/clsn.bson
2018-01-08T16:59:18.178+0800    reading metadata for clsn.clsn1 from /home/mongod/backup/oplog/clsn/clsn1.metadata.json
2018-01-08T16:59:18.216+0800    restoring clsn.clsn1 from /home/mongod/backup/oplog/clsn/clsn1.bson
2018-01-08T16:59:18.669+0800    restoring indexes for collection clsn.clsn1 from metadata
2018-01-08T16:59:18.679+0800    finished restoring clsn.clsn1 (3165 documents)
2018-01-08T16:59:19.850+0800    restoring indexes for collection clsn.clsn from metadata
2018-01-08T16:59:19.851+0800    finished restoring clsn.clsn (10000 documents)
2018-01-08T16:59:19.851+0800    replaying oplog
2018-01-08T16:59:19.919+0800    done

　　注意黃字體，第一句表示clsn.clsn1集合中恢復了3165個文檔；第二句表示重放了oplog中的全部操做。因此理論上clsn1應該有16857個文檔（3165個來自clsn.bson，剩下的來自oplog.bson）。驗證一下：

sh1:PRIMARY> db.clsn1.count()
3849

　　這就是帶oplog的mongodump的真正做用。

1.3.4 從別處而來的oplog

oplog有兩種來源：

一、mongodump時加上--oplog選項，自動生成的oplog，這種方式的oplog直接 --oplogReplay 就能夠恢復

 

二、從別處而來，除了--oplog以外，人爲獲取的oplog

例如：

mongodump  --port 28021 -d local -c oplog.rs

　　既然dump出的數據配合oplog就能夠把數據庫恢復到某個狀態，那是否是擁有一份從某個時間點開始備份的dump數據，再加上從dump開始以後的oplog，若是oplog足夠長，是否是就能夠把數據庫恢復到其後的任意狀態了？是的！

　　事實上replica set正是依賴oplog的重放機制在工做。當secondary第一次加入replica set時作的initial sync就至關因而在作mongodump，此後只須要不斷地同步和重放oplog.rs中的數據，就達到了secondary與primary同步的目的。

　　既然oplog一直都在oplog.rs中存在，咱們爲何還須要在mongodump時指定--oplog呢？須要的時候從oplog.rs中拿不就完了嗎？答案是確定的，你確實能夠只dump數據，不須要oplog。

在須要的時候能夠再從oplog.rs中取。但前提是oplog時間窗口必須可以覆蓋dump的開始時間。

及時點恢復場景模擬

模擬生產環境

for(i=0;i<300000;i++){ db.oplog.insert({"id":i,"name":"shenzheng","age":70,"date":new Date()}); }

   插入數據的同時備份

mongodump -h 10.0.0.152 --port 28021  --oplog  -o /home/mongod/backup/config

    備份完成後進行次錯誤的操做

    db.oplog.remove({});

備份oplog.rs文件

mongodump -h 10.0.0.152 --port 28021 -d local -c oplog.rs -o  /home/mongod/backup/config/oplog

   恢復以前備份的數據

mongorestore -h 10.0.0.152 --port 28021--oplogReplay /home/mongod/backup/config

   截取oplog，找到發生誤刪除的時間點

bsondump oplog.rs.bson |egrep "\"op\":\"d\"\,\"ns\":\"test\.oplog\"" |head -1 
"t":1515379110,"i":1

   複製oplog到備份目錄

cp  /home/mongod/backup/config/oplog/oplog.rs.bson   /home/mongod/backup/config/oplog.bson

   進行恢復，添加以前找到的誤刪除的點（limt）

mongorestore -h 10.0.0.152 --port 28021 --oplogReplay --oplogLimit "1515379110:1"  /home/mongod/backup/config

　　   至此一次恢復就完成了

1.3.5 mongodb的備份準則

只針對replica或master/slave，知足這些準則MongoDB就能夠進行point-in-time恢復操做：

 

  1. 任意兩次數據備份的時間間隔（第一次備份開始到第二次備份結束）不能超過oplog時間窗口覆蓋範圍。
  2. 在上次數據備份的基礎上，在oplog時間窗口沒有滑出上次備份結束的時間點前進行完整的oplog備份。請充分考慮oplog備份須要的時間，權衡服務器空間狀況肯定oplog備份間隔。

實際應用中的注意事項：

 

  1. 考慮到oplog時間窗口是個變化值，請關注oplog時間窗口的具體時間。
  2. 在靠近oplog時間窗口滑動出有效時間以前必需要有足夠的時間dump出須要的oplog.rs，請預留足夠的時間，不要頂滿時間窗口再備份。
  3. 當災難發生時，第一件事情就是要中止數據庫的寫入操做，以往oplog滑出時間窗口。特別是像上述這樣的remove({})操做，瞬間就會插入大量d記錄從而致使oplog迅速滑出時間窗口。

分片集羣的備份注意事項

一、備份什麼？

　　（1）configserver

　　（2）每個shard節點

二、備份須要注意什麼？

　　（1）元數據和真實數據要有對等性（blancer遷移的問題，會形成config和shard備份不一致）

 

　　（2）不一樣部分備份結束時間點不同，恢復出來的數據就是有問題的。

1.4 MongoDB監控

爲何要監控？

監控及時得到應用的運行狀態信息，在問題出現時及時發現。

監控什麼？

CPU、內存、磁盤I/O、應用程序（MongoDB）、進程監控（ps -aux）、錯誤日誌監控

1.4.1 MongoDB集羣監控方式

db.serverStatus()

　　查看實例運行狀態（內存使用、鎖、用戶鏈接等信息）

　　經過比對先後快照進行性能分析

"connections"     # 當前鏈接到本機處於活動狀態的鏈接數
"activeClients"   # 鏈接到當前實例處於活動狀態的客戶端數量
"locks"           # 鎖相關參數
"opcounters"      # 啓動以後的參數
"opcountersRepl"  # 複製想關
"storageEngine"   # 查看數據庫的存儲引擎
"mem"             # 內存相關

狀態:

db.stats()

顯示信息說明：

  "db" : "test" ,表示當前是針對"test"這個數據庫的描述。想要查看其餘數據庫，能夠先運行$ use databasename(e.g  $use admiin).
　"collections" : 3,表示當前數據庫有多少個collections.能夠經過運行show collections查看當前數據庫具體有哪些collection.
　"objects" : 13，表示當前數據庫全部collection總共有多少行數據。顯示的數據是一個估計值，並非很是精確。
　"avgObjSize" : 36,表示每行數據是大小，也是估計值，單位是bytes
　"dataSize" : 468,表示當前數據庫全部數據的總大小，不是指佔有磁盤大小。單位是bytes
　"storageSize" : 13312,表示當前數據庫佔有磁盤大小，單位是bytes,由於mongodb有預分配空間機制，爲了防止當有大量數據插入時對磁盤的壓力,所以會事先多分配磁盤空間。
　"numExtents" : 3,彷佛沒有什麼真實意義。我弄明白以後再詳細補充說明。
　"indexes" : 1 ,表示system.indexes表數據行數。
　"indexSize" : 8192,表示索引佔有磁盤大小。單位是bytes
   "fileSize" : 201326592，表示當前數據庫預分配的文件大小，例如test.0,test.1，不包括test.ns。

1.4.2 mongostat

　　實時數據庫狀態，讀寫、加鎖、索引命中、缺頁中斷、讀寫等待隊列等狀況。

　　每秒刷新一次狀態值，並能提供良好的可讀性，經過這些參數能夠觀察到MongoDB系統總體性能狀況。

[mongod@MongoDB oplog]$ mongostat -h 10.0.0.152 --port 28017 
insert query update delete getmore command flushes mapped  vsize   res faults qr|qw ar|aw netIn netOut conn set repl                      time
    *0    *0     *0     *0       0     1|0       0        303.0M 13.0M      0   0|0   0|0  143b     8k    1      RTR 2018-01-08T17:28:42+08:00

參數說明： 

參數

參數說明

insert

每秒插入量

query

每秒查詢量

update

每秒更新量

delete

每秒刪除量

conn

當前鏈接數

qr|qw

客戶端查詢排隊長度（讀|寫）最好爲0，若是有堆積，數據庫處理慢。

ar|aw

活躍客戶端數量（讀|寫）

time

當前時間

mongotop命令說明：

[mongod@MongoDB oplog]$ mongotop  -h 127.0.0.1:27017
2018-01-08T17:32:56.623+0800    connected to: 127.0.0.1:27017

                                               ns    total    read    write    2018-01-08T17:32:57+08:00
                               admin.system.roles      0ms     0ms      0ms                             
                               admin.system.users      0ms     0ms      0ms                             
                             admin.system.version      0ms     0ms      0ms                             
                                         app.user      0ms     0ms      0ms                             
             automationcore.automation.job.status      0ms     0ms      0ms                             
                 automationcore.config.automation      0ms     0ms      0ms                             
        automationcore.config.automationTemplates      0ms     0ms      0ms                             
automationcore.config.automationTemplates_archive      0ms     0ms      0ms                             
         automationcore.config.automation_archive      0ms     0ms      0ms                             
                 automationstatus.lastAgentStatus      0ms     0ms      0ms

mongotop重要指標

ns：數據庫命名空間，後者結合了數據庫名稱和集合。
total：mongod在這個命令空間上花費的總時間。
read：在這個命令空間上mongod執行讀操做花費的時間。
write：在這個命名空間上mongod進行寫操做花費的時間。

1.4.3 db級別命令

db.currentOp()

　　查看數據庫當前執行什麼操做。

　　用於查看長時間運行進程。

　　經過（執行時長、操做、鎖、等待鎖時長)等條件過濾。

　　若是發現一個操做太長，把數據庫卡死的話，能夠用這個命令殺死他：> db.killOp(608605)

db.setProfilingLevel()

　　設置server級別慢日誌

　　打開profiling：

0:不保存

1:保存慢查詢日誌

 

2:保存全部查詢日誌

　　注意:級別是對應當前的數據庫，而閾值是全局的。

查看profiling狀態

查看慢查詢：system.profile

 

關閉profiling

企業工具ops manager官方文檔： https://docs.opsmanager.mongodb.com/v3.6/

1.5 MongoDB集羣性能優化方案

1.5.1 優化方向

硬件（內存、SSD）

收縮數據

增長新的機器、新的副本集

集羣分片鍵選擇

chunk大小設置

 

預分片（預先分配存儲空間）

1.5.2 存儲引擎方面

　　WiredTiger是3.0之後的默認存儲引擎，細粒度的併發控制和數據壓縮提供了更高的性能和存儲效率。3.0之前默認的MMAPv1也提升了性能。

　　在MongoDB複製集中能夠組合多鍾存儲引擎，各個實例實現不一樣的應用需求。

1.5.3 其餘優化建議

收縮數據

預分片

增長新的機器、新的副本集

集羣分片鍵選擇

 

chunk大小設置

1.6 附錄：Aliyun 備份策略

1.6.1 MongoDB雲數據庫備份/恢復

 

備份策略：

  1. 從hidden節點備份
  2. 天天一次全量備份
  3. 持續拉取oplog增量備份
  4. 按期巡檢備份有效性
  5. 恢復時克隆到新實例

1.6.2 全量備份方法

 

1.6.3 邏輯備份流程 - mongodump

 

特色：

  1. 全量遍歷全部數據、
  2. 備份、恢復慢
  3. 對業務影響較大
  4. 無需備份索引、恢復時重建
  5. 通用性強

1.6.4 物理備份流程

 

備份特色

  1. 拷貝數據目錄全部文件，效率高
  2. 備份、恢復快
  3. 對業務影響較小
  4. 跟數據庫版本、配置強關聯

1.6.5 邏輯備份 vs 物理備份

 

邏輯備份

物理備份

備份效率

低

數據庫接口讀取數據

高

拷貝物理文件

恢復效率

低

下載備份集 +  導入數據 +  創建索引

高

下載備份集 +  啓動進程

備份影響

大

直接與業務爭搶資源

小

備份集大小

比原庫小

無需備份索引數據

與原庫相同

兼容性

兼容絕大部分版本

可跨存儲引擎

依賴存儲佈局

   更多內容參考http://www.mongoing.com/archives/3962

1.7 參考文獻

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程