MongoDB Setup Architecture for multiple Datacenter

With changing weather and more frequent hurricane and storms, the disasters hitting datacenters became the real threat. To make the critical applications run even in the event of a disaster became an important goal for the organizations. Setting up the redundancy is a cost but it helps in achieving reliability and also makes maintenance easier to perform.

This post will guide you through the architecture consideration to setup MongoDB with redundancy within a datacenter as well as redundancy between two datacenters.

If you want to replicate same set of data between the both datacenters there is no point of going with the Sharding .

These are the requirements for setting up an automatic fail-over MongoDB cluster:

·         To setup the replication of data between two data centers.

·         Automatic fail over to the secondary data center in case of any Disaster event.

·         Not to have single point of failures in primary as well as secondary site.

Based on these requirements and after going through MongoDB resources on the replica set setup this can be proposed architecture.

·   We don’t want to have any single point of failure in any of the datacenter so we should provision at least two nodes in each datacenter. Make sure these nodes are running on the separate servers (boxes) so that the hardware redundancy of the servers can also be taken care.

·     For automatic fail-over, we need to make sure that the majority of voting members are still running after a failure in the primary data center. We should have 4 data-bearing nodes, and one arbiter. Mongo chooses the Master node based on the total majority of the member votes (more than 50% to choose a master) 

·      To make sure that no primary step down in case the secondary site is unavailable (the reverse situation), the arbiter should be in a third location as the probability of two locations going down at once is quite low in comparison of one location . This third location can be even a cloud based datacenter. 

·      We assigned higher priority to Node in primary datacenter and lower priority to the node in the secondary datacenter so that if the node in primary datacenter is available it will be getting elected. We by design keep gap between the priority number in primary and secondary datacenter so that if in future we have to add more nodes we can add them without going for decimal values. 

DATACENTER	NODE	PRIORITY
Primary	I	9
Primary	II	8
Secondary	III	5
Secondary	IV	4

In case you need detailed setup instructions for such architecture, it can be found on the MongoDB website Deploy a Distributed Four Member Replica Set