Disaster Recovery, Replication, Fault Tolerance and High Availability for Your MongoDB.
ObjectRocket currently offers options for Sharded and Replica MongoDB instances, but behind the scenes we always use 3 member replica sets for data redundancy and fault tolerance. Sharded instances consist of dedicated mongos servers, config servers, and the shards themselves, which are each a 3 member replica set.
However, disaster recovery is a different matter. ObjectRocket offers a disaster recovery scheme where your Sharded and Replica MongoDB instances receive mirrored member replica sets in another datacenter at an additional cost that can be utilized in case of a disaster event.
All ObjectRocket managed MongoDB instances come with high availability, replication (Data Redundancy) and fault tolerance as a package.
High Availability is important.
High availability by its name refers to your ability to access your data at all times and this can be achieved with various technologies. However, a key component to almost any HA solution is a replica of your data. This is where data redundancy comes into play and you only see one database, but behind the scenes, there are two or more exact copies (replicas) of that data which helps in shifting from one replica set node to another in the case of failure.
Fault Tolerance
Fault tolerance is the property that enables a system to continue operating properly in the event of failure of a component within the same fault zone. To ensure business continuity, we use different hosts or servers for each of your shards Replica set members, therefore, if one goes down the others are operational.
Replication (Data Redundancy)
MongoDB Replication is the process of synchronizing data across multiple servers at an application level. Replication provides redundancy and increases data availability with multiple copies of data on different database servers. Replication protects a database from the loss of a single server and allows you to recover from hardware failure and service interruptions. With additional copies of the data, you can dedicate one or more to disaster recovery, reporting, or backup.
Disaster Recovery (Optional, But Nice to Have)
Disaster Recovery (DR) is an area of planning that aims to protect an organization from the effects of significant negative events like natural calamities, power failure that can cause data center level outage. The goal of DR is for a business to continue as close to normal as possible.
Use Case – Without Disaster Recovery
Let’s assume a scenario where you have high sales all throughout the year but especially on Cyber Monday and across the holiday seasons.
What would the architecture look like?
As a United States based company you would like your data to be stored within the United States, so we will use our DFW datacenter to store your data and IAD datacenter to keep a backup.
High Availability is achieved by having your data mirrored to two nodes that are acting as SECONDARY nodes, should the PRIMARY fail due to any reason, a SECONDARY would become the new PRIMARY node and yet, still have another backup. In the meantime our support team will ensure the node that failed is recovered and in sync with the new PRIMARY.
MongoDB can scale out horizontally via single large Replica sets using one PRIMARY and two SECONDARY nodes with heartbeat communication for up/down state with Replication (Data Redundancy) occurring to the secondaries via the oplog.
Fault Tolerance is achieved by having each host or ‘bricks’ (as we like to refer to them) on different hardware within the same datacenter, so in case of hardware failure, your MongoDB is operational.
Generally a shard could also be a single MongoDB instance; however, as previously mentioned, Replica sets on ObjectRocket include 3 MongoDB instances as presented below.
Shard
- DFWNODE1 – PRIMARY
- DFWNODE2 – SECONDARY
- DFWNODE3 – SECONDARY
How High Availability, Data Redundancy and Fault Tolerance Work in ObjectRocket
In the case of any maintenance, downtime, or failure, the PRIMARY can be switched with any of the SECONDARY nodes and continue without issue, thus taking advantage of High Availability.
Data is replicated from the PRIMARY node to the SECONDARY nodes via the oplog thus achieving Data Redundancy.
In regards to Fault Tolerance, let’s imagine the unlikely scenario that the server that hosts one of the Replica set members breaks down, be it the PRIMARY or any of the SECONDARY nodes, your MongoDB instance will continue to run in a 2 node Replica set until the support team can remediate the issue.
With Disaster Recovery
Our scheme works in mirroring your current instance (regardless of the amount of shards you have added to your instance) in one of our closest datacenters respective to the instance. We would additionally have a disaster recovery plan set up in IAD for you. The IAD Replica set members would be connected to the PRIMARY node in DFW3, with your data replicated in a synchronous manner across regions ensuring your data is up to date, as illustrated in the example below.
Shard
- DFWNODE1 – PRIMARY
- DFWNODE2 – SECONDARY
- DFWNODE3 – SECONDARY
- IADNODE1 – SECONDARY
- IADNODE2 – SECONDARY
- IADNODE3 – SECONDARY
We’re Here and Ready to Help
High Availability, Replication and Fault Tolerance ties in together with Disaster Recovery on the ObjectRocket platform, plus we back all of this up with smart people – keeping you safe and stable during all your peak times. Visit our Managed MongoDB page to learn more or reach out directly either through chat or email. We look forward to working with you and would love the opportunity to earn your business.