云数据库 MongoDB：MongoDB实例空间使用率高问题

当云数据库MongoDB实例为分片集群架构时，您可以登录MongoDB管理控制台通过以下方法查看空间使用情况：

• 监控图分析

  在监控信息页面，选择目标节点，查看目标节点的磁盘空间使用量（Bytes）和磁盘空间使用率（%）。

• 详细分析

  通过云数据库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. 查看索引物理文件大小。

云数据库MongoDB 4.0以前的版本，如果宿主机的open files达到设置上限，则会使云数据库MongoDB内部的log server清理线程中断，进而使Journal Log过大导致空间无限上涨，当通过云数据库MongoDB的运行日志查看到类似以下内容时，您可以将内核版本升级到云数据库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值，云数据库MongoDB通过内部的哈希函数可以使得数据均匀地分布在不同地分⽚上，⽽range分⽚⼀般是根据key的⼤⼩范围进⾏数据分布，所以往往会造成这样的⼀个现象：新插⼊的数据在⼀个热点的chunk上，不但会引起该chunk所在的shard磁盘I/O过⾼，也会带来短期数据不均匀的场景。

各个分⽚上的chunk数量基本⼀致，但实际上绝⼤部分数据都只存储在部分chunk上，导致这些热点chunk所在的分⽚上的数据量远远⼤于其他分⽚上的数据量，执行命令sh.status()查看云数据库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" }

针对上述问题，我们建议：

• 如果是因为⽬标集群初始化导⼊，导⼊之前做好分⽚设计。

• 如果不做分片的库很多且数据量基本相当，通过云数据库MongoDB提供的命令movePrimary将指定数据库迁移到指定分⽚。

• 如果存在某个数据库的数据量极⼤且未做分片，建议对其做分片设计或者将其拆分出来当作单⼀的副本集对待。

• 如果出现这种情况，但磁盘空间足够大，建议忽略该问题。