MongoDB : Replica Sets

Previous: MongoDB the shell unpeeled

Typically we have a primary server along with a backup server. If the primary fails and if you are well prepared ( and if everything goes well) we can restore the primary from the  backup.

MongoDB uses the concept of replication which is a much better alternative to traditional backup solutions. Mongo uses an arrangement called the Relica Set. The members of the Relica Set are a Primary DB, Secondary DB(s) and an Arbiter DB (potentially). Each of these servers play a specific role in the Replica Set

Primary DB: This is the one and only writable instance. So all clients and applications that need to write to the database must connect to the primary to issue a write command. An attempt to write to a secondary will fail.

Secondary Database(s) are read only instances. You can have many secondary databases which means a high availability of scalability, so that you can issue reads against different databases without having to compromise issuing read and write commands on a single server. Data will be replicated to the secondary  databases from the primary database eventually and hence known as “Eventual Consistency”.

Arbiter Database is special because it does not have any data on it. Its sole purpose is to break a tie in an election ( Will be covered shortly). Because of that, the arbiter could be on a much smaller machine (very less memory, CPU and HDD space). It just needs to be around to break the tie, if an election is needed so as to nominate the primary server. Arbiters are not mandatory. If you have an odd number of servers in a server farm, then automatically one server will be nominated as the primary server

At some point, if the primary database fails, one of the secondary database(s) will take over as primary. This is great because it gives the cluster a far greater resilience against a single point failure.

If one of the secondary fails, its not a big deal, because the primary is available (you can issue reads against it) and if in a server farm situation, there will be other secondaries to read from.  Therefore no data loss, or no loss of functionality.

Lets go over the different scenarios where an election can take place in case the primary fails and the overall role of the arbiter in the tie breaking process.

Scenario 1:  Primary  fails and a secondary database needs to be promoted to primary.

Mongo promotes the secondary base to a primary database based on the results of an election. The election rules are that you have to have a simple majority in order to promote a secondary to a primary (including the old primary !)

If you had an even number of servers, say a primary and a secondary and the primary disappeared or some reason, the secondary does not automatically  become the primary, because its the only voter.

The math for an election is pretty simple. If you start a replica set with three members and if the primary fails, there are two members remaining each one with a vote. The secondary would vote or itself and the arbiter will always vote for another machine (i.e. it wont vote for itself). In this case we have a clear majority and the secondary gets promoted to primary

If instead you had only 2 machines, i.e. primary and secondary  (no arbiter) and the primary fails. The secondary will vote for itself, but it wont be a majority. since it only makes up 50% of the vote. This is where the arbiter comes in, so that it can tilt the vote to a majority.

Setting up a Replica Set

Setting up a replica set is no different from setting up the MongoD server. In development you could set up all three on the same machine with different TCP ports. In production it would be advisable to opt for three servers in a minimal configuration.

Next Up : A simple replication set configuration

.For all your application development needs, visit www.verbat.com for a fiscally conscious proposal that meets your needs ( So I can keep this blog going as well!!!!)

Alternatively click through the link   if you found this article interesting. (This will help the companies Search engine rankings)