Standby & DR Sharded Cluster

[Daniel Pinto]

Hello everyone,

Currently, we have a production environment with the following MongoDB sharded cluster:

• Machine 1:
• Router
• Config (replica member)
• Shard

• Machine 2:
• Config (replica member)
• Shard

• Machine 3:
• Config (replica member)
• Shard

We know that this deployment does not provide high availability since the shards are not in a replica set. 

In a near future, we will have more machines for standby (same data center) and disaster recovery (another data center). 

What's your suggestion for this case?

Many thanks,

Daniel Pinto

[Rhys Campbell]

Add two SECONDARY servers to each replset at a minimum

https://docs.mongodb.com/manual/tutorial/deploy-shard-cluster/

I'd locate one secondary from each replset to your DR site. Ideally your put the mongos/config servers on their own hosts too. Assuming your app runs in the primary data centre too you'd want to make sure your reads stay in this data centre. Also set the priority of the servers in the DR lower than the other data centre so the PRIMARY stays in the MAIN site (usually).

[Daniel Pinto]

Hello Rhys,

Thanks for your reply.

I'm considering a migration to the following architecture:

Production

• Machine 1:
• Router 1
• Config (Replica 0 - Member 1)
• Shard (Replica 1 - Member 1)

• Machine 2:
• Shard (Replica 2 - Member 1)

• Machine 3:
• Shard (Replica 3 - Member 1)

Standby 

• Machine 1:
• Router 2
• Config (Replica 0 - Member 2)
• Shard (Replica 1 - Member 2)

• Machine 2:
• Shard (Replica 2 - Member 2)

• Machine 3:
• Shard (Replica 3 - Member 2)

Disaster Recovery

• Machine 1:
• Router 3
• Config (Replica 0 - Member 3)
• Shard (Replica 1 - Member 3)

• Machine 2:
• Shard (Replica 2 - Member 3)

• Machine 3:
• Shard (Replica 3 - Member 3)

What do you think? Is this a viable sharded cluster or should I consider other options?

Many thanks.

[Kevin Adistambha]

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:

• Production Notes
• Operations Checklist
• Development Checklist
• Security Checklist

Best regards,
Kevin

​