How to recover a single shard cluster with majority of replica set members unavailable?

Working with Data
,
4

Gday folks!

@steevej: There is no performance benefit setting up a single shard as a sharded cluster, but one motivation for a single shard deployment is when you anticipate adding further shards for scaling in the reasonably near future.

A sharded cluster involves extra configuration and resources (config servers, mongos ) that are not required in a replica set deployment, but if you start with this configuration you will have fewer operational changes to make when you start adding shards (for example, no change to your connection string or backup procedures).

@Kim_Hakseon: Since you have lost a majority of members for a shard replica set, you can force reconfigure the replica set using one of the surviving members. I would emphasise the docs description that this is only intended as an emergency procedure:

The force option forces a new configuration onto the member. Use this procedure only to recover from catastrophic interruptions. Do not use force every time you reconfigure. Also, do not use the force option in any automatic scripts and do not use force when there is still a primary.

As far as arbiters go: my recommendation would be to never have more than one, and ideally avoid using arbiters altogether in modern versions of MongoDB. For more background, please see my response on Replica set with 3 DB Nodes and 1 Arbiter - #8 by Stennie_X.

Regards,
Stennie

1 Like