0

I have set up a replica set of mongoDB with one primary, one secondary and one arbiter node, mongoDB installed on three independent AWS instances. I need to document overall availability of the replica set cluster formed as per aforementioned configuration but don't have any reliable/standard data to establish so.

Is there any standard data which can be referred to establish avaialability of overall cluster/individual node in above case?

AIPDS CoE
  • 1
  • 1
  • What are you looking to describe in terms of availability? The replica set configuration really only describes fault tolerance. With 3 members your replica set can tolerate failure/unavailability of 1 member and maintain write availability with a primary. However, since you have an arbiter the consequences of having a member unavailable depend on whether that member is the arbiter or a secondary. An arbiter does not store any data, so If the unavailable member is a secondary your replica set will no longer have any active replication or be able to ack a majority write concern. – Stennie Feb 28 '18 at 11:56
  • If you are referring to expected availability of your AWS instances, you would have to review the [EC2 SLA](https://aws.amazon.com/ec2/sla/) and uptime commitment for the services you are using. The SLA guarantee typically requires deploying into multiple Availability Zones and only considers unplanned outages (not scheduled maintenance). If you follow all the right caveats you may get a [99.99% SLA](https://uptime.is/99.99) which results in credits for service outages. The SLA is just compensation if a minimum level of service is not maintained; observed availability could be higher or lower. – Stennie Feb 28 '18 at 12:17

1 Answers1

0

Your configuration will guarantee continued availability, even after one node goes down. However, availability after that depends on how quickly you can replace the downed node, and that is up to your monitoring and maintenance abilities.

If you do not notice for while that a node is down, or if your procedure for replacing the node takes a long time (you may need to commission a new VM, install MongoDB, reconfigure the replica set, allow time for the new node to sync), then another node may go down and leave you with no availability.

So your actual availability depends on the answers to four questions:

  1. Which replica set configuration do you use? Because that determines how many nodes need to go down before the replica set stops being available
  2. How likely it is that any single node will go down or lose connection to the rest?
  3. How good is your monitoring, so you notice there is a problem?
  4. How fast are your processes for repairing the problem?

The answer to the first one is straightforward; you have decided on the minimum of two data-bearing nodes and one arbiter.

The answer to the second one is not quite straightforward; it depends on the reliability of each node, and the connections between them, and whether two or more are likely to go down together (perhaps if they are in the same availability zone).

The third and fourth, we can't help you with; you'll have to assess those for yourself.

Vince Bowdren
  • 8,326
  • 3
  • 31
  • 56