If you are using a Replica Set with your MongoDB setup you might be wondering why using an odd number of nodes (or members) is the best practice. After all if you could have four nodes that is probably better than three, right? Not so fast! In this post we will dig in a little deeper into why an odd number of nodes in a Replica Set is nearly always better than an even number.
Stepping back a bit let’s review why we have Replica Sets in the first place:
Don’t Let Your Server Stand Alone
While a single “standalone” setup is suitable for local development or experimentation, it falls short in production environments due to its inherent vulnerability as a “single point of failure.”
Imagine the repercussions if your lone server experiences network hiccups, crashes unexpectedly, or faces other unforeseen events. The result? Your application or website grinds to a halt. Worse still, restoring your lone server could be an arduous task, the duration of which remains uncertain.
Replica Sets and Replication
To obliterate the threat of a single point of failure, MongoDB uses the concept of database replication. This idea might sound familiar if you’ve encountered it in other database systems. Replication involves duplicating a database’s content across multiple servers. Should one server falter, a backup server springs into action, mirroring the original setup and data. In MongoDB, this potent technique is realized through “Replica Sets.”
At the heart of a Replica Set stands the Primary server, the singular nexus for database reads and writes. This Primary server doesn’t work in isolation; it diligently replicates its data across one or more secondary servers, creating redundancy.
As in the example above, setting up a Replica Set often involves initiating at least three mongod instances or nodes. While it’s possible to run these nodes on the same physical server, doing so still harbors a single point of failure. Ideally, each node should reside on a separate physical server for maximum resilience.
Elections and Promotions
Upon a Replica Set’s initiation, each node engages in a dance of data exchange, configuring themselves and laying the groundwork for what’s known as an “election.” This election, a democratic process amongst nodes, crowns one node as the Primary. While the intricacies of this process are fascinating, let’s save those details for later. In our current context, suffice it to say that in a three-node setup, one Primary is elected while the remaining two nodes become Secondaries.
This happens because with three nodes voting they can either vote for themselves, or another node. So, you either end up with each node voting for themself (which creates a tie, and triggers a new election) or one node gets at least two votes, and “wins” the election by a majority.
This is where an odd number of nodes becomes so important! You may be thinking that by adding another node, this Replica Set is more resilient. However, it provides the same amount of protection as three nodes as seen in this illustration:
With either three nodes or four nodes, you can only lose one node and still have a majority. If you have four nodes and lose two, a majority is not possible, since it will be two votes out of four. If you have five nodes, a majority is possible, and you could lose up to two nodes, and so on.
You can have as many as 50 nodes in a replica set, but only up to 7 of those nodes can vote.
We will delve into Replica Sets more in future posts, but also feel free to check out my book MongoDB for Jobseekers (see more info below.)
