Alternative approach to shards migration

[subin94]

As per the documentation https://docs.couchdb.org/en/3.1.0/cluster/sharding.html, when a new node is added to the cluster, CouchDB will not redistribute existing database shards to it, leading to load issues. Migrating shards of a database (say DB_X) manually can be a risky process too.

Suggested Approach

Instead of manually migrating the shards, what if we create a new database (say DB_Y) and replicate the data from the existing database DB_X to this new database DB_Y. This way, I believe shards for the database DB_Y will be equally distributed to the new node too.

Obviously this will consume additional disk space and change of database name need to be handled at application layer.
Are there any other issues that I am overlooking here?

[wohali]

That's a completely acceptable approach, assuming your client application(s) can handle it, and your nodes have sufficient storage for both databases at once.

You also have to rebuild all of the views and Mango secondary indexes; for some, this is prohibitively expensive.

Finally, keep in mind that for a cluster of >3 nodes, you can't necessarily guarantee balancing across all machines will be automatically generated. For even bigger clusters, if your # of nodes is greater than the total number of shard replicas (by default in 3.x: q*n = 2*3 = 6) you absolutely will have an unbalanced cluster.

If you care significantly about a perfectly balanced cluster, and your databases are big & your views are computationally intensive, you'll need to consider manual balancing.