Smoothly converting Sharded Cluster to Replica Set

151 views

Skip to first unread message

nnt

unread,

Apr 19, 2016, 1:41:55 AM4/19/16

to mongodb-user

MongoDB documentation shows how to convert a sharded cluster to a replica set: https://docs.mongodb.org/manual/tutorial/convert-sharded-cluster-to-replica-set/

The problem with this process is that it requires downtime to the applications. I am think of this way for a smooth transition from sharded cluster to replica set:

With applications still working with the sharded cluster, remove all other shards except for one shard that can hold all data of other shards (you can add a new big shard before doing this)
Point applications to this sole shard
Decommission the remaining unused sharded cluster infrastructure

Could this be so solution to be applied in production for zero downtime transition? I do not really understand why the doc is showing the process which introduces application downtime and the complexity of dumping and restoring data (see this section).

Thank you.

Kevin Adistambha

unread,

Apr 29, 2016, 1:47:02 AM4/29/16

to mongodb-user

With applications still working with the sharded cluster, remove all other shards except for one shard that can hold all data of other shards (you can add a new big shard before doing this)

Point applications to this sole shard

Decommission the remaining unused sharded cluster infrastructure

Yes you are correct. Currently as of MongoDB 3.2, you can use these steps to convert a sharded cluster into a replica set (assuming your shards are replica sets). Essentially you are reconfiguring your cluster into a single shard, then using that remaining shard as a replica set afterward. This method is outlined in the page Convert a Cluster with a Single Shard into a Replica Set.

However, please note there is no guarantee that these steps will still work in future versions of MongoDB, hence the page Convert a Sharded Cluster into a Replica Set describes a “safe” method that will work for the foreseeable future.

Also, if you have a lot of shards, draining the whole cluster into a single shard may take much longer vs. dumping and restoring the collection. The tradeoff is, it does involve downtime during the migration process.

As with any operations involving major changes to your deployment, please remember to backup your data and thoroughly examine any possible failure scenarios involving your deployment beforehand.