Why would one shard receive a disproportion amount of traffic in a sharded cluster? What can prevent a sharded cluster from balancing? Why do chunk migrations affect sharded cluster performance? • Your cluster may be over capacity, and you may want to attempt to add one or two shards (page 697) to the cluster to distribute load. • You may want to attempt decreasing the chunk size (page 727) to limit the size of the migration. 2. If the balancer is always migrating chunks to the detriment of overall cluster performance: 1. If migrations only interrupt your clusters sporadically, you can limit the balancing window (page 716) to prevent balancing activity during peak hours. Ensure that there is enough time remaining to keep the data from becoming out of balance again. – poor network connectivity between shards, which may lead to chunk migrations that take too long to complete. Investigate your network configuration and interconnections between shards. – an uneven distribution of write operations (page 675) that requires more data migration. You may have to choose a different shard key to resolve this issue. – a balancing window (page 716) that is too short, given the rate of data growth. • Your data set is growing faster than the balancer can distribute data around the cluster. This is uncommon and typically is the result of: • Your shard key has low cardinality (page 696) and MongoDB cannot split the chunks any further. • You have deleted or removed a significant amount of data from the cluster. If you have added additional data, it may have a different distribution with regards to its shard key. MongoDB Documentation, Release 3.0.4 As a related problem, the system will split chunks only on inserts or updates, which means that if you configure sharding and do not continue to issue insert and update operations, the database will not create any chunks. You can either wait until your application inserts data or split chunks manually (page 723). Finally, if your shard key has a low cardinality (page 696), MongoDB may not be able to create sufficient splits among the data. In some situations, a single shard or a subset of the cluster will receive a disproportionate portion of the traffic and workload. In almost all cases this is the result of a shard key that does not effectively allow write scaling (page 675). It’s also possible that you have “hot chunks.” In this case, you may be able to solve the problem by splitting and then migrating parts of these chunks. In the worst case, you may have to consider re-sharding your data and choosing a different shard key (page 694) to correct this pattern. If you have just deployed your sharded cluster, you may want to consider the troubleshooting suggestions for a new cluster where data remains on a single shard (page 782). If the cluster was initially balanced, but later developed an uneven distribution of data, consider the following possible causes: If migrations impact your cluster or application’s performance, consider the following options, depending on the nature of the impact: 783 11.9. FAQ: MongoDB Diagnostics