Sitecore xDB: Creating Replication Set for MongoDB

My last post was about enabling authentication on Sitecore MongoDB and use the same in a connection string so that sitecore can connect to MongoDB via authentication. In case you have missed it for reading you can find it at “Sitecore xDB Enabling Authentication”. This post is somewhat related to the previous post as the scenario remains the same of deploying mongo databases for a production environment with a new challenge added. The challenge was to create a replication set which will help to overcome xDB failures and high availability of analytics data. Going through the documentation on configuring xDB from xDB™ Configuration Guide”, Sitecore also recommends to have a replication set configured for xDB. We followed Single Server Setup for MongoDB, below are the explanatory notes about Single Server Setup.

Single replica set – The minimum recommended configuration for production, which should have at least 2.5 servers: two full capacity data servers for failover and one low capacity server for the arbiter. Sitecore recommends three data servers for a robust and resilient deployment, especially during maintenance.

Theory

Below diagram shows an ideal recommended Mongo DB setup by sitecore,

MongoDB Replication Set

Primary

The primary accepts all write operations from clients. Replica set can have only one primary. Because only one member can accept write operations, replica sets provide strict consistency for all reads from the primary.

Secondary

The secondaries replicate the primary’s oplog and apply the operations to their data sets. Secondaries’ data sets reflect the primary’s data set. If the primary is unavailable, the replica set will elect a secondary to be primary. By default, clients read from the primary, however, clients can specify a read preferencesto send read operations to secondaries. Reads from secondaries may return data that does not reflect the state of the primary.

Arbiter

You may add an extra mongod instance to a replica set as an arbiter. Arbiters do not maintain a data set. Arbiters only exist to vote in elections. If your replica set has an even number of members, add an arbiter to obtain a majority of votes in an election for primary. Arbiters do not require dedicated hardware.

Practical

Till this point of writing, the post was more about understanding the MongoDB configuration and roles. Now let’s see how to set it up.

All the help for creating a mongo db replication set is well documented at MongoDB Manual specifically at “Replication Introduction”, however I will mention the exact precise steps that will get you going with MongoDB replication set configured with Sitecore.

Steps for creating  xDB replication set are,

1) Install MongoDB on all the three servers (primary, secondary and arbiter), this is the simplest steps of all.

2) Verify network configuration between all the three mongodb instances so that it allows all possible connections between each other. Also check your firewall settings. If you are looking for testing the connections read “Test Connections Between all Members”.

3) Create administrative users on any one of the MongoDB instance

a) In command prompt navigate to \MongoDB 2.6 Standard\bin folder
b) Connect to mongo shell and then connect to admin database using “use admin” command
c) Execute the following command to create users.

[code language=”xml”]
db.createUser( {
user: "siteUserAdmin",
pwd: "siteUserAdmin@xDB",
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
});
[/code]

mongo Admin User
4) Create a root user, Why do we need a root user?
Provides access to the operations and all the resources of the readWriteAnyDatabase, dbAdminAnyDatabase, userAdminAnyDatabase and clusterAdmin roles combined. Also replication set cannot be initiated if you are not logged in as root user.

Execute below commands to create a root user,

[code language=”xml”]
db.createUser( {
user: "siteRootAdmin",
pwd: "siteRootAdmin@xDB",
roles: [ { role: "root", db: "admin" } ]
});

[/code]

Root_User

5) Stop Mongo instance.

6) Create the key file to be used by each member of the replica set. MongoDB will use the default challenge-response authentication and hence keyFile will supply the password and allows connections between the members of replication set.

Initially I thought to include keyfile generation in this post itself but to keep it simple for your reading, have a look at “Creating keyFile for xDB Replication Set” post for creating the keyFile.

7) Copy the key file to each member of the replica set.

8) Add config file to each member mongo instances (mongod.cfg), your config file should look something like,

[code language=”xml”]

logpath=C:\MongoDB 2.6 Standard\logs\mongo.log

dbpath=C:\MongoDB 2.6 Standard\Databases

keyFile=C:\MongoDB 2.6 Standard\bin\mongodb-keyfile

auth=true

replSet=RS-xDBProd
[/code]

9) Configure all mongod to run as a service and start the service. Are you thinking how to configure mongod to run as a service? This post might help “Sitecore xDB Enabling Authentication”.

10) Connect to mongo shell on the mongod instance where you created administrative user and execute below commands

[code language=”xml”]
use admin

db.auth("siteUserAdmin","siteUserAdmin@xDB")
[/code]

11) Initiate replication set using,

[code language=”xml”]
rs.initiate()
[/code]

You can check the status of the replication set by issuing rs.status() command.

mongo replication initiate

The prompt should now show ReplicaSetName:Primary

12) Add secondary member to the replication set

[code language=”xml”]
rs.add("172.16.2.15")
[/code]

mongo secondary
13) Add Arbiter to the replication set

[code language=”xml”]
rs.addArb("172.16.2.47")
[/code]

14) Finally check the status of the replication set

[code language=”xml”]
rs.status()
[/code]

rs-arbiter

This is all you need to get MongoDB running as a replication set for Sitecore xDB.