MongoDB for Sitecore Production Environment

MongoDB setup on your local dev environment is rather easy task. Basically you download MongoDB, install it and configure mongod (database process) to run as a Windows Service. All connection strings are already by default in your Sitecore ConnectionStrings.config file. That’s easy. But how to deal with it on production environment, when things are more complicated, cause you have to ensure required level of availability. In other words you need to be sure that your Sitecore solution will still work, even if some of its component, hosting MongoDB fails.

The easiest way to provide such setup is using MongoDB replication. How does it work?

You start with MongoDB installation on more machines: at least on two (or rather three, if you use arbiter) and configure replica set. In this set you have separate mongod process running on each machine, connected with each other. Every node in the set has its own role:

1. Primary – this is the primary data storage used for read & write. If data in your MongoDB is modified it’s replicated from this node to Secondary node(s).
2. Secondary – this is the secondary data storage used for read. There could be more than one Secondary node in the set. If Primary fails one of the Secondary nodes may become the new Primary.
3. Arbiter – the only role of this node is to promote one of the Secondary node to become the new Primary, in case Primary instance failed. Arbiter doesn’t store the data.

Sitecore communicate with Primary and Secondary nodes, each instance in the replica set should also be able to communicate with the others.

 

Replica set configuration

Prerequisites

We need to install & run MongoDB on all machines and check if all nodes are able to talk with each other. We can use telnet or try to connect to MongoDB instance using mongo shell command from your MongoDB installation folder:

Repeat this step on all machines and try to connect to all instances.
Output should be “connecting to: mongo2.smartsitecore.com:27017/test”

Primary node configuration

First we need to change mongod configuration file on Primary by adding following lines (if you don’t use YAML syntax, just add replSet=rs0). rs0 will be the name of our set:

After changing configuration it’s necessary to restart mongod process. Now we are ready to call mongo shell again on Primary node:

result should be { “ok” : 1}

Secondary node configuration

We need to change mongod configuration file on Secondary by adding same lines as on Primary:

Restart mongod on Secondary node. Then on the Primary node run rs.add() command from mongo shell

Again result should be { “ok” : 1}

Arbiter node configuration

Change mongod configuration file on Arbiter, by adding the same replication set name and disable journal for storage (for non YAML syntax use journal.enabled=false). You can safely disable journal, cause Arbiter will not store any data, besides the configuration.

Restart mongod on Arbiter node. Then on the Primary node run rs.addArb() command from mongo shell

Result should be again { “ok” : 1}

Checking Replica set status

We need again run mongo shell command on one of the instances and call replication status command:

the output should look like below. We have three nodes in the set and all are operating:

We can now turn of mongod on Primary or Secondary data storage and observe what happens to replicate set using rs.status(). If Primary is down, Arbiter will automatically promote Secondary to become Primary.

Configure Sitecore to use MongoDB replica set

Finally we can update default Sitecore connection strings to point to replica set:

This setup guarantee improved performance and automatic failover. Data is synchronized automatically between Primary and Secondary MongoDB instances.