MongoDB Replica Set High Availability Notes

MongoDB offers a strong solution for High Availability via the Replica Set High Availability setup. DBAs work with HA and become familiar with the behaviour during setup and management, there is also a requirement to communicate with application teams some of the HA behaviour. Developers can use this information to design their applications

In the examples below - we are using a 3 node cluster set. 

A 3 node cluster replica set has a fault tolerance supporting unavailability of 1 node while still having a Primary Node and the ability to still write to the Primary. If 2 nodes become unavailable, the sole survivor becomes a secondary. With any read preference other than  primary you could still service reads in the sole survivor node scenario.

This "flow chart" (?) - depicts the 3 different scenarios we're discussing

Scenario 1 – All MongoDB server active

Server1 (Primary) – read & write

Server2 (Secondary)  - read

Server3 (secondary) – read

Scenario 2 – One of the 3 node replica set becomes unavailable

Server1 (Primary) – read & write

Server2 (Primary)  - read & write

Server3 (secondary) – read

Scenario 3 – two of the All MongoDB servers become unavailable, Note:  the sole survivor server remains as Secondary and is read only

Server1 (Primary) – read & write

Server2 (Secondary)  - read

Server3 (secondary) – read

The MongoDB 3 node replica set HA cluster is built in a way that will allow the ability to  write to a Primary , but then optionally  read from a Secondary. You’ll need to read more on your driver documentation but essentially there will be need to be a usage of readPreference=secondaryPreferred  or readPreference=secondary switch. This can also be tested with other clients such as command line and MongoCompass.

If you design the application to read from secondaries you will have to deal with the possibility of intermittent latency or  eventual consistency

This step i.e using readPreference=secondaryPreferred is not strictly necessary , but the next point highlights that when you get to scenario 3 – it looks like it’s required

When we get to scenario 3 – the app will only be able to connect by exploiting the readPreference switch, as it is a secondary server .  You can't have a primary node accepting writes without a majority. You can still read from a secondary when there's no primary. You just need to set a secondary read preference.