當(dāng)云數(shù)據(jù)庫MongoDB實例為分片集群架構(gòu)時，您可以登錄MongoDB管理控制臺通過以下方法查看空間使用情況：

• 監(jiān)控圖分析

  在監(jiān)控信息頁面，選擇目標(biāo)節(jié)點，查看目標(biāo)節(jié)點的磁盤空間使用量（Bytes）和磁盤空間使用率（%）。

• 詳細分析

  通過云數(shù)據(jù)庫MongoDB自身提供的命令db.stats()和db.$collection_name.stats()依次分析各個節(jié)點的空間使用情況。

首先在備庫上執(zhí)行命令db.runCommand({compact:"collectionName"})，然后進行主備切換，以減少compact期間對業(yè)務(wù)的影響。其中collectionName為集合名稱，請根據(jù)實際情況替換。

compact的基本原理并不是??開辟新的空間存放數(shù)據(jù)來替換原來的?件，?是將數(shù)據(jù)不斷地往前?的空間空洞挪動，所以在某些場景下雖然存在空間空洞，但內(nèi)部的compact算法并不能保證肯定可以復(fù)?這些空洞，我們稱之為compact無效。compact無效的場景和解決方法如下：

• 在完成compact后，雖然提示操作成功，但實際上磁盤空間并沒有回收，對于該場景，建議您通過重建副本的方式解決。

• MongoDB 3.4以前的版本，在刪除大量數(shù)據(jù)后，compact?法回收索引文件，只對數(shù)據(jù)?件?效，對于該場景，建議您將內(nèi)核版本升級?3.4以上。您可以通過如下方法確認該場景：

  1. 執(zhí)行命令db.$table_name.stats().indexSizes。

  2. 查看索引物理文件大小。

云數(shù)據(jù)庫MongoDB 4.0以前的版本，如果宿主機的open files達到設(shè)置上限，則會使云數(shù)據(jù)庫MongoDB內(nèi)部的log server清理線程中斷，進而使Journal Log過大導(dǎo)致空間無限上漲，當(dāng)通過云數(shù)據(jù)庫MongoDB的運行日志查看到類似以下內(nèi)容時，您可以將內(nèi)核版本升級到云數(shù)據(jù)庫MongoDB 4.0以上，或者通過重啟云數(shù)據(jù)庫mongod進程進行臨時解決，詳情請參見log-server thread exit quietly on error while the mongodb process still running。

2019-08-25T09:45:16.867+0800 I NETWORK [thread1] Listener: accept() returns -1 Too many open files in system 
2019-08-25T09:45:17.000+0800 I - [ftdc] Assertion: 13538:couldn't open [/proc/55692/stat] Too many open files in system src/mongo/util/processinfo_linux.cpp 74
2019-08-25T09:45:17.002+0800 W FTDC [ftdc] Uncaught exception in 'Location13538: couldn't open [/proc/55692/stat] Too many open files in system' in full-time diagnostic data capture subsystem. Shutting down the full-time diagnostic data capture subsystem.

對于以上兩種場景，通過對Oplog單獨做compact操作解決，具體如下：

db.grantRolesToUser("root", [{db: "local", role: "dbAdmin"}])
use local
db.runCommand({ compact: "oplog.rs", force: true })

在?個分?集群中，?鍵類型的選擇?關(guān)重要，?般會使?hash分?或者ranged分?兩種類型。通常情況下，在磁盤均衡度??，hash分?的策略會?ranged好很多，因為根據(jù)不同的key值，云數(shù)據(jù)庫MongoDB通過內(nèi)部的哈希函數(shù)可以使得數(shù)據(jù)均勻地分布在不同地分?上，?range分??般是根據(jù)key的??范圍進?數(shù)據(jù)分布，所以往往會造成這樣的?個現(xiàn)象：新插?的數(shù)據(jù)在?個熱點的chunk上，不但會引起該chunk所在的shard磁盤I/O過?，也會帶來短期數(shù)據(jù)不均勻的場景。

各個分?上的chunk數(shù)量基本?致，但實際上絕?部分數(shù)據(jù)都只存儲在部分chunk上，導(dǎo)致這些熱點chunk所在的分?上的數(shù)據(jù)量遠遠?于其他分?上的數(shù)據(jù)量，執(zhí)行命令sh.status()查看云數(shù)據(jù)庫MongoDB的運行日志，從日志中可以查看到以下類似告警信息：

2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260000" } 
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260200" } 
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260230" }

針對上述問題，我們建議：

• 如果是因為?標(biāo)集群初始化導(dǎo)?，導(dǎo)?之前做好分?設(shè)計。

• 如果不做分片的庫很多且數(shù)據(jù)量基本相當(dāng)，通過云數(shù)據(jù)庫MongoDB提供的命令movePrimary將指定數(shù)據(jù)庫遷移到指定分?。

• 如果存在某個數(shù)據(jù)庫的數(shù)據(jù)量極?且未做分片，建議對其做分片設(shè)計或者將其拆分出來當(dāng)作單?的副本集對待。

• 如果出現(xiàn)這種情況，但磁盤空間足夠大，建議忽略該問題。