ApsaraDB for MongoDB：MongoDB執行個體空間使用率高問題

當ApsaraDB for MongoDB執行個體為分區叢集架構時，您可以登入MongoDB管理主控台通過以下方法查看空間使用方式：

• 監控圖分析

  在監控資訊頁面，選擇目標節點，查看目標節點的磁碟空間使用量（Bytes）和磁碟空間使用率（%）。

• 詳細分析

  通過ApsaraDB for MongoDB自身提供的命令db.stats()和db.$collection_name.stats()依次分析各個節點的空間使用方式。

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

compact的基本原理並不是⽴⻢開闢新的空間存放資料來替換原來的⽂件，⽽是將資料不斷地往前⾯的空間空洞挪動，所以在某些情境下雖然存在空間空洞，但內部的compact演算法並不能保證肯定可以複⽤這些空洞，我們稱之為compact無效。compact無效的情境和解決方案如下：

• 在完成compact後，雖然提示操作成功，但實際上磁碟空間並沒有回收，對於該情境，建議您通過重建副本的方式解決。

• MongoDB 3.4以前的版本，在刪除大量資料後，compact⽆法回收索引檔案，只對資料⽂件⽣效，對於該情境，建議您將核心版本升級⾄3.4以上。您可以通過如下方法確認該情境：

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

  2. 查看索引物理檔案大小。

ApsaraDB for MongoDB 4.0以前的版本，如果宿主機的open files達到設定上限，則會使ApsaraDB for MongoDB內部的log server清理線程中斷，進而使Journal Log過大導致空間無限上漲，當通過ApsaraDB for MongoDB的作業記錄查看到類似以下內容時，您可以將核心版本升級到ApsaraDB for MongoDB 4.0以上，或者通過重啟雲資料庫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 })

在⼀個分⽚叢集中，⽚鍵類型的選擇⾄關重要，⼀般會使⽤hash分⽚或者ranged分⽚兩種類型。通常情況下，在磁碟均衡度⽅⾯，hash分⽚的策略會⽐ranged好很多，因為根據不同的key值，ApsaraDB for MongoDB通過內部的雜湊函數可以使得資料均勻地分布在不同地分⽚上，⽽range分⽚⼀般是根據key的⼤⼩範圍進⾏資料分布，所以往往會造成這樣的⼀個現象：新插⼊的資料在⼀個熱點的chunk上，不但會引起該chunk所在的shard磁碟I/O過⾼，也會帶來短期資料不均勻的情境。

各個分⽚上的chunk數量基本⼀致，但實際上絕⼤部分資料都只儲存在部分chunk上，導致這些熱點chunk所在的分⽚上的資料量遠遠⼤於其他分⽚上的資料量，執行命令sh.status()查看ApsaraDB for 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" }

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

• 如果是因為⽬標叢集初始化導⼊，導⼊之前做好分⽚設計。

• 如果不做分區的庫很多且資料量基本相當，通過ApsaraDB for MongoDB提供的命令movePrimary將指定資料庫遷移到指定分⽚。

• 如果存在某個資料庫的資料量極⼤且未做分區，建議對其做分區設計或者將其拆分出來當作單⼀的複本集對待。

• 如果出現這種情況，但磁碟空間足夠大，建議忽略該問題。