Mongodb – restore mongodb sharded cluster to another server

If you lose one of the three config servers, you just halt migrations, so in a balanced system where you're not exceeding 80% capacity, you should have hours and hours of time to page the duty DBA and bring back that one server.

You could virtualize them or place them on management band / highly reliable servers if you really can't afford to have down time for the cluster to perform chunk migration over a long weekend or other situation where you're not attentive to the config servers.

Most of your planning will be to make sure you understand the network partition scenarios and that the primary stays running and you have enough secondaries to serve read loads as needed. It's hard to generalize other than:

• Add arbiters to keep the voting members an odd number.
• Test your outage scenarios
• Scale the system so you can actually perform rolling outages and verify that things work well without killing your application in practice. You might not test at peak load, but you should be able to take rolling outages routinely several times a week until you're confident in your tools, scripts and configuration.

I will try to be brief. Most of the answers are documented.

Q1: There are many ways. Shard a collection using _id:hashed and set initial number of chunks 2 and then start inserting documents (100 is a good number of docs). You will see documents on both shards.

Q2: It uses range partitioning. Each shard holds ranges of the shard key.

Q3: Sharding is an automated process, all you need to do is to determine a shard key.

Q4: Stop the balancer, backup shard rs1, rs2 and the config server, start the balancer.

Q5: On a sharded cluster the access point should be the mongos