Balancing performance after adding a shard

Ops and Admin Sharding
,
9

There is an option of resharding twice, that would be much faster and less impactful on your system. You would need to be on MongoDB 5.0 or later and make sure you have enough spare disk storage capacity. Please read this article to understand the concept behind it.

  • Let’s say your shard key is userId:1. You would reshard to the hashed version of your shard key, so userId:"hashed" then reshard again back to your original shard key of userId:1.

  • Let’s say your shard key is state:1,city:1. You would reshard to the hashed version of your shard key, so state:"hashed",city:1 then reshard again back to your original shard key of state:1,city:1.

Depending on how much data you have per shard, each resharding could take anywhere from a day to a week. This works much faster because resharding writes to all shards in parallel instead of migrating data one chunk at-a-time.

The upside is that it’s much faster than chunk balancing/migration and has almost no impact on your workload (since you simply drop the old collection), meaning you can run it 24/7. But you must ensure that you have enough spare disk space for it. (Please read the resharding documentation)

Since you are resharding to the hashed version of your shard key and then back, you DO NOT need to rewrite your application’s queries to use both the current shard key and the new shard key. You can simply reshard twice without any changes to your application.