背景
某客户反馈某个MongoDB Sharding集群中，各个分片节点chunk分布严重不均衡，且每天晚上在迁移窗口（activeWindow）进行chunk迁移操作在日志均报错失败，需要分析原因。
影响面
各分片节点数据严重倾斜，数据无法自动均衡。
环境
MongoDB版本: 3.4.9
分片节点: 3个mongos节点，三个config server节点，后端三个分片节点，分片副本集名称分别为shard1、shard2和shard3。
问题定位思路及流程
查看sh.status()输出，因修改部分表名和集合名；
从sh.status()的输出中可以发现db01_xxx库中col01_xxxx_info和col01_xxxx_info_2019在后端各个shard的chunk数量已经严重不均衡，前者chunk数量之差47470-43068为4402个chunk，后者37053-29为37024个chunk，遇到这种情况，第一反应是看config primary的日志，MongoDB默认情况会开启balancer进程在各个shard之间迁移chunk来让shard间的chunk数量基本保持一致，chunk迁移的方向是从chunk数量最多的分片往chunk数量最少的分片迁移，在3.2版本及以下，balancer进程由Mongos发起，如果有多个Mongos进程，多个Mongos会竞争一把锁，谁获得锁谁就将获得运行balancer进程的权限，但是在3.4版本及以后，balance进程已经放在了config server的Primary节点，这样就不会有锁竞争这一过程了，查看config primary的在迁移窗口的日志有大量如下报错：
2019-05-27T00:04:06.140+0800 I SHARDING [Balancer] Balancer move db01_xxx.col01_xxxx_info_2019: [{ col01_column_1: "3177000047924787", sharedDate: new Date(1546561546000) }, { billingContractNo: "3177000049293528", sharedDate: new Date(1548383450000) }), from shard2, to shard1 failed :: caused by :: ConflictingOperationInProgress: Unable to start new migration because this shard is currently donating chunk [{ col01_column_1: "3177000525560227", sharedDate: new Date(1527215797000) }, { col01_column_1: "3177000525560227", sharedDate: new Date(1527217436000) }) for namespace db01_xxx.col01_xxxx_info to shard3
从日志得到以下信息：
1. 存储col01_xxxx_info_2019集合的chunk的迁移方向是从shard2往shard1迁移，shard2 chunk数量最多，shard1数量最少，现象符合。
2. 存储col01_xxxx_info集合的chunk的迁移方向是从shard1往shard3迁移（donating chunk），shard1数量最多，而shard3 chunk数量最少，现象符合。
3. 第1点失败的原因是第二点，原因是自动迁移的进程产生了冲突（ConflictingOperationInProgress）并等待，从而导致迁移失败。
该现象与MongoDB已知的BUG现象基本一致，该BUG表示当存在多个集合的自动的数据均衡操作时，分片节点不能同时作为源端和目标端，BUG链接为：Sharding balancer schedules multiple migrations with the same conflicting source or destination[链接1]（相关链接见文末）
修复验证
通过日志及相关信息可知，db01_xxx.col01_xxxx_info集合的数据较为均衡，可临时通过以下命令将该集合的自动Balancer停用，防止db01_xxx.col01_xxxx_info_2019做数据迁移时出现冲突，相关命令如下：
// 禁用自动balance
sh.disableBalancing("db01_xxx.col01_xxxx_info");
// 启用自动balance
sh.enableBalancing("db01_xxx.col01_xxxx_info");
结论
1. MongoDB balancer进程启动后，通常会在两种情况下来决定是否要做迁移使用 removeShard 后分片数量发生了变化会做自动迁移；
通过对比持有chunk最多和最少的shard, 集合的chunk数量在各个后端shard之间的数量达到一定的差值时会触发自动迁移，迁移阈值[链接2]（相关链接见文末）如下：
| 集合chunk数量 | 迁移阈值 |
|---|---|
| <20 | 2 |
| <80 | 4 |
| >=80 | 8 |
2. 该BUG在MongoDB 3.4.11版本以下会触发，3.4.11及以上版本，3.6版本均已修复，因此要想解决此问题需要将集群升级到3.4.11版本以上。
相关链接
[链接1] https://jira.mongodb.org/browse/SERVER-29423
[链接2] https://docs.mongodb.com/manual/core/sharding-balancer-administration/#migration-thresholds
近期社区动态
