1.1 MongoDB的常用命令
mongoexport / mongoimport
mongodump / mongorestore
有以上兩組命令在備份與恢復中進行使用。
1.1.1 導出工具mongoexport
Mongodb中的mongoexport工具可以把一個collection導出成JSON格式或CSV格式的文件。可以通過參數指定導出的數據項，也可以根據指定的條件導出數據。
該命令的參數如下：
| 參數 |
參數說明 |
| -h |
指明數據庫宿主機的IP |
| -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的對比
- mongoexport/mongoimport導入/導出的是JSON格式，而mongodump/mongorestore導入/導出的是BSON格式。
- JSON可讀性強但體積較大，BSON則是二進制文件，體積小但對人類幾乎沒有可讀性。
- 在一些mongodb版本之間，BSON格式可能會隨版本不同而有所不同，所以不同版本之間用mongodump/mongorestore可能不會成功，具體要看版本之間的兼容性。當無法使用BSON進行跨版本的數據遷移的時候，使用JSON格式即mongoexport/mongoimport是一個可選項。跨版本的mongodump/mongorestore並不推薦，實在要做請先檢查文檔看兩個版本是否兼容（大部分時候是的）。
- 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有兩種來源：
1、mongodump時加上--oplog選項，自動生成的oplog，這種方式的oplog直接 --oplogReplay 就可以恢復
2、從別處而來，除了--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恢復操作：
- 任意兩次數據備份的時間間隔（第一次備份開始到第二次備份結束）不能超過oplog時間窗口覆蓋范圍。
- 在上次數據備份的基礎上，在oplog時間窗口沒有滑出上次備份結束的時間點前進行完整的oplog備份。請充分考慮oplog備份需要的時間，權衡服務器空間情況確定oplog備份間隔。
實際應用中的注意事項：
- 考慮到oplog時間窗口是個變化值，請關注oplog時間窗口的具體時間。
- 在靠近oplog時間窗口滑動出有效時間之前必須要有足夠的時間dump出需要的oplog.rs，請預留足夠的時間，不要頂滿時間窗口再備份。
- 當災難發生時，第一件事情就是要停止數據庫的寫入操作，以往oplog滑出時間窗口。特別是像上述這樣的remove({})操作，瞬間就會插入大量d記錄從而導致oplog迅速滑出時間窗口。
分片集群的備份注意事項
1、備份什么？
（1）configserver
（2）每一個shard節點
2、備份需要注意什么？
（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雲數據庫備份/恢復
備份策略：
- 從hidden節點備份
- 每天一次全量備份
- 持續拉取oplog增量備份
- 定期巡檢備份有效性
- 恢復時克隆到新實例
1.6.2 全量備份方法
1.6.3 邏輯備份流程 - mongodump
特點：
- 全量遍歷所有數據、
- 備份、恢復慢
- 對業務影響較大
- 無需備份索引、恢復時重建
- 通用性強
1.6.4 物理備份流程
備份特點
- 拷貝數據目錄所有文件，效率高
- 備份、恢復快
- 對業務影響較小
- 跟數據庫版本、配置強關聯
1.6.5 邏輯備份 vs 物理備份
| 邏輯備份 |
物理備份 |
|
| 備份效率 |
低 數據庫接口讀取數據 |
高 拷貝物理文件 |
| 恢復效率 |
低 下載備份集 + 導入數據 + 建立索引 |
高 下載備份集 + 啟動進程 |
| 備份影響 |
大 直接與業務爭搶資源 |
小 |
| 備份集大小 |
比原庫小 無需備份索引數據 |
與原庫相同 |
| 兼容性 |
兼容絕大部分版本 可跨存儲引擎 |
依賴存儲布局 |
更多內容參考http://www.mongoing.com/archives/3962
1.7 參考文獻
[1] http://www.cnblogs.com/yaoxing/p/mongodb-backup-rules.html
[2] http://blog.itpub.net/15498/viewspace-2073272/
[3] http://www.mongoing.com/archives/3962
[4] http://chenzhou123520.iteye.com/blog/1641319