一、CPU/IOPS打滿
結合mongostat和mongotop分析MongoDB各資源情況以及讀寫耗時。
#查看最近慢日誌
db.system.profile.find().sort({$natrual: -1})
- 全表掃描
關注關鍵字“COLLSACN、docsExamined”，對全表掃描查詢（或者更新/刪除）建立合理索引進行優化。
- 不合理查詢
關注關鍵字“IXSCAN、keysExamined”，對於複合索引，需要注意索引建立的前後順序，以及對排序的優化。
- 大量數據排序
關注關鍵字“SORT、hasSortStage”，如果SQL需要對大量的數據進行排序，且排序無法通過索引來進行排序，MongoDB會把結果集放在內存進行排序，非常消耗CPU資源。可以考慮通過索引降低結果集大小或者利用索引進行排序來進行優化。
查看執行計劃
db.t1.find({id:1}).explain()
#抓取正在執行的會話
db.currentOp()
//關注參數
client | 請求是由哪個客戶端發起的
opid | 操作的opid，有需要的話，可以通過db.killOp(opid) 直接終止該操作
secs_running/microsecs_running | 這個值重點關注，代表請求運行的時間，如果這個值特別大，請看看請求是否合理
query/ns | 這個字段能看出是對哪個集合正在執行什麼操作
lock* | 些跟鎖相關的參數
//kill會話
db.killOp(opid)
三、活躍連接數打高
//抓取正在執行的會話
db.currentOp()
//關注參數
client | 請求是由哪個客戶端發起的
opid | 操作的opid，有需要的話，可以通過db.killOp(opid) 直接終止該操作
secs_running/microsecs_running | 這個值重點關注，代表請求運行的時間，如果這個值特別大，請看看請求是否合理
query/ns | 這個字段能看出是對哪個集合正在執行什麼操作
lock* | 些跟鎖相關的參數
//kill會話
db.killOp(opid)
//同時針對可優化SQL進行優化
//查看最近慢日誌
db.system.profile.find().sort({$natrual: -1})
四、磁盤打高/滿
#獲取mongoDB中數據庫的大小命令
use databasename
db.stats()
#獲取MongoDB中collection
db.collection.dataSize()
//collection中的數據大小
db.collection.storageSize()
//爲collection分配的空間大小，包括未使用的空間
db.collection.totalIndexSize()
collection中索引數據大小
db.collection.totalSize()
//回收空間
use somedb
db.runCommnd({compact: "somecollection"})
// compact oplog，在副本集primary上執行需要加 force 選項
use local
db.runCommnd({compact: "somecollection", force: true})
五、副本集故障
5.1 複製延遲
- 網絡延遲：減小副本集節點之間的網絡延遲。
- 磁盤吞吐量：保證磁盤吞吐。
- 併發：併發大的情況下，primary節點上的一些耗時操作會阻塞secondary節點的複製操作，導致複製操作跟不上主節點的寫入負荷。解決方法是通過設置操作的write concern。默認的副本集中寫入操作只關心primary節點，但是可以指定寫入操作同時傳播到其他secondary節點，代價就是嚴重影響集羣的併發性。
- 注意：而且這裏還存在一個問題如果，如果寫入操作關心的某個節點宕機了，那麼操作將會一直被阻塞直到節點恢復。
- 適當的write concern：我們爲了提高集羣寫操作的吞吐量經常會將writer concern設置爲unacknowledged write concern，這導致primary節點的寫操作很快而secondary節點複製操作跟不上。解決方法和第三點是類似的就是在性能和一致性之間做權衡。
5.2 複製中斷
當secondary節點落後太多無法追趕上primary節點的時候，這時候可能需要考慮重新同步數據（Resync data）。
有兩種方法一種是指定一個空的目錄重新啓動落後的節點，這很簡單，但是數據量大的情況下回花費很長的時間。另一種方法是基於另一個節點的數據作爲“種子”進行重新同步
六、分片故障
6.1 shard節點宕機
1、新建shard節點並啓動
2、在mongos上刪除原shard節點的配置信息
3、添加新shard節點的配置信息
七、數據丟失
1、通過備份使用mongorestore/mongoimport恢復數據
2、建立延遲從庫
3、因爲oplog具有冪等性，通過實時拷貝oplog做數據恢復
八、其它場景
8.1 內存打高
1、合理配置cacheSizeGB參數
1）如果服務器上只運行MongoDB服務，默認配置即可
2）如果服務器上還有別的服務運行，建議設置cacheSizeGB參數爲可用內存的60%
2、控制併發連接數
1）MongoDB driver 在連接 mongod 時，會維護一個連接池（通常默認100），當有大量的客戶端同時訪問同一個mongod時，就需要考慮減小每個客戶端連接池的大小
2）通過net.maxIncomingConnections限制MongoDB併發連接數，防止數據庫過載
3、配置swap
1）如果配置了swap，可以有效的防止MongoDB服務出現OOM，但是當內存不足時，頻繁的使用swap會嚴重影響數據庫性能。
2）最優的場景是爲MongoDB服務配置充足的內存，內存不足及時擴容
4、其他
1）儘量減少內存排序的場景，內存排序一般需要更多的臨時內存
2）主備節點配置差距不要過大，備節點會維護一個buffer（默認最大256MB）用於存儲拉取到oplog，後臺從buffer裏取oplog不斷重放，當備同步慢的時候，這個buffer會持續使用最大內存。
3）控制集合及索引的數量，減少databse管理元數據的內存開銷；集合、索引太多，元數據內存開銷是一方面的影響，更多的會影響啓動加載的效率、以及運行時的性能。