For a production application, it is quite common to use mongodb as a replica set. Unfortunately, mongodb replica sets support for Meteor was no so good in versions prior to 0.6.4. But with the version 0.6.4, now Meteor support for replica sets is really good.
With this tutorial, I will go through the replica sets basics and how to configure it for Meteor.
Replica Sets is the way how mongodb handles replication. Replication is really important for a production application since we cannot guarantee about the 100% availability. If something goes wrong, we should need some backup. Replica Sets is an option for that. Replica sets can also be used to scale mongodb (on read operations), but it’s commonly used for High Availability and Fault Tolerance.
With replica sets, you can run few mongodb instances (normally 3) in sync. Mostly all of your data is synced between these nodes.
There is a
primary node, which accepts all the write and read operations. Other nodes are called
secondaries and they are subscribed to primary for receiving write operations.
If the primary goes down, one of the secondaries will become the new primary. All of these electing processes are handled by the replica set itself, and we don’t need to do any manual intervention.
Please note that there are some other ways we can configure the behavior of replica sets.
For this tutorial, we are creating a 3 node mongodb replica set. And we run all of these replica sets in our local machine. (just for the demonstration purpose). You can go through my replica set short notes for setting it up.
I assume you’ve gone through that process and now you’ve got a 3 nodes replica set as shown below
Our replica set name is meteor
Now we need to create our replica set aware MONGO_URL as shown below.
Now lets start our meteor app with this MONGO_URL
Now our app runs with a MongoDB Replica Set.
Still there are couple of options you need to be aware, when configuring your app. Here they are.
It is really important to set read preference value to
primaryPreferred as it avoids crashing meteor while there is a new primary election.
With write concern, you can control the consistency level in the replica set. That means you can wait for mongodb to respond back to you for a write operation, after it completed write operation on all nodes, none or in between those two.
It is recommended to to use write concern value
majority for replica sets. But it is not a bad idea to use it as
1 since we are not always reading from the secondaries.
Now with all these options, our final MONGO_URL will be something like below.
Give it a try and share your experiences.