Subject: [mongodb-user] Re: Standby & DR Sharded

Hi Daniel

I’m not certain why you need to split the deployment into 3 different names (Production, Standby, and Disaster Recovery), since if I understand correctly, they’re all part of a single sharded MongoDB deployment, even though they’re located within different data centers.

From your description of your deployment topology, I would recommend:

  • Not run multiple mongod in the same machine, since this would create a resource contention. Instead, it’s best to have a single machine dedicated to a single mongod. This would ensure each mongod can extract the maximum performance of the underlying hardware.
  • Not run the config server mongod within the shards themselves. Config servers contain vital information for your sharded cluster.
  • You could run the mongos query routers in the same machine as your application servers, instead of within the deployment machines.
  • I believe there is no need to designate part of the cluster to be “Standby” or “Disaster Recovery”, for two reasons: 1) A replica set secondary is doing just as much work as the primary, so it’s not in “standby” by any means. 2) Parts marked as “Disaster recovery” is still part of the same deployment.
  • For disaster recovery purposes, you might want to check out MongoDB backup methods

For optimal performance, you may want to align your deployment to the recommended settings described in the following links:

Best regards,

You received this message because you are subscribed to the Google Groups "mongodb-user"
For other MongoDB technical support options, see:
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at
To view this discussion on the web visit
For more options, visit

Programming list archiving by: Enterprise Git Hosting