MongoDB 分片磁盘出现不均问题

 

liuwei 创建于 2018-08-13 08:30；更新于 2018-08-13 08:32

问题描述：

现在的问题是 d-2ze3c57fd30b1294 这个分片的磁盘使用是 32.7%
而 d-2ze509f107c83dc4 shard 磁盘的使用才 17.6% 相差快一倍了，数据量大的集合基本上都是分块数均匀的，为什么不同的 shard 磁盘使用却有这么大的差距，mongo 不是有自动 balance 的能力么？为什么磁盘的空间还有这么大的差距？能给一下比较详细的解释原因吗？不然以后我们的 mongo 集群总是受 d-2ze3c57fd30b1294 shard 磁盘的短板所累。

阿里技术专家给的相关解释

• 情况1:

  可能存在分片键选择不合理，如某个值大量重复出现，这样就会造成某个 chunk 需要加载大量的数据，而到达一定 split chunk 条件也没办法进行 split ,该 chunk 数据量会越来越大，从而造成该 chunk 所在的 shard 空间也会越来越大。

• 其它情况，这是阿里专家给的该问题的解释
  目前

1. d-2ze3c57fd30b1294 空间最大那个shard，因为大量的迁移产生了很多删除oplog，主备同步有延时；备上目前同步已经把cpu、内存都跑满了再追赶
2. 这个shard上，有一些脏数据，mongo层已经删除了，但物理文件还没有删除（50G左右），等同步完了，你重启一下这个shard，mongo会自动清理这些脏数据的。

关于阿里给出解释的继续追问：

shard 磁盘空间存在比较大的差异，我有以下几个疑惑：

• 1，大量的迁移是指 shard 间的，还是指该 shard 主备间的？如果假设是 shard 间的，从各个 shard 磁盘的使用情况来看，也没有此消彼长的情况出现，如果假设是主备间的，这种情差异况已经持续了很长时间了（从下图对比中可以发现），在这么长的时间内怎么就没迁移好。
• 2，mongo 层已经删除了，为什么物理层不删除，是出于什么原因？请给与解答。

阿里专家给出的解释如下：

• 1、物理层不回收，跟存储引擎的机制有关，大部分现代存储引擎都是这么去实现的比如 一个mongo的集合，会对应wiredtiger的物理文件你导入了很多数据，比如整个文件涨到100G了，中间因为迁移或者你自己删了很多数据比如20G，中间会产生很多空洞，但这些空洞的物理空间是不会立马回收掉的（文件仍然是100G，而不会立马变成80G）; 这些空洞虽然不能立即物理回收，但接下来的写入就能复用，可能你再导入20G，他的物理文件也不怎么涨了，还是100G左右。
• 2、嗯，但 d-2ze3c57fd30b1294 有 50GB 这样的空间，前天当磁盘显示已经满的时候，按说我们的写，应该还是能写进去的，但我们这边的写操作都报错了。
  目前实例锁定的时候是按物理文件大小统计的