MongoDB Replication and Sharding

MONGODB
Database R&D Documentation
Document Control
Document Location
Location
10.0.1.96Team SharesDB_ActivitiesORACLEMongoDB
Template History
Author Date Version Changes
Tharun B &
Tharun Kumar M
21/09/2015 1.0 Document Created
Revision History
Author Date Versi
on
Revision Description
Tharun B 07/09/2015 1.0 Introduction to MongoDB
Approvals
Name Role Reviewed Version
Approved
Approval Date
Kishore Kumar I Lead – DBA No NA NA

Replication Introduction
Replication is the process of synchronizing data across multiple servers.
Purpose of Replication
Replication provides redundancy and increases data availability.With multiplecopies of data on different database
servers,replication protects a databasefrom the loss of a singleserver. Replication also allows you to recover from
hardware failure and service interruptions. With additional copies of the data, you can dedicate one to disaster
recovery, reporting, or backup.
In some cases, you can use replication to increase read capacity. Clients have the ability to send read and write
operations to different servers. You can also maintain copies in different data centers to increase the locality and
availability of data for distributed applications.
Replication in MongoDB
A replica setis a group of mongod instances thathostthe samedata set. One mongod, the primary,receives all write
operations.All other instances,secondaries,apply operations fromtheprimary so that they have the same data set.
The primary accepts all writeoperations fromclients.Areplica setcan haveonly oneprimary. To supportreplication,
the primary records all changes to its data sets in its oplog. For more information on primary node operation, see
Replica Set Primary.
Diagram of default routing of reads and writes to the primary.

The secondaries replicatethe primary’s oplogand apply the operations to their data sets such that the secondaries’
data sets reflect the primary’s data set. If the primary is unavailable, the replica set will elect a s econdary to be
primary. Below is a diagram of a 3 member replica set that consists of a primary and two secondaries.
Arbiter: When there is a primary failover,oneof the secondary nodes has to become the primary.Arbiter acts as an
authority and votes among the eligible secondary nodes in order to make it a primary node.
Below is a diagram of a replica set that consists of a primary, a secondary, and an arbiter.
Note: An arbiter will always be an arbiter whereas a primary may step down and become a secondary and a
secondary may become the primary during an election.

During Automatic Failover
When a primary does not communicate with the other members of the set for more than 10 seconds,the replica set
will attempt to select another member to become the new primary.The firstsecondary that receives a majority of
the votes becomes primary. Below is a diagramof an election of a new primary. In a three member replica setwith
two secondaries , the primary becomes unreachable. The loss of a primary triggers an election where one of the
secondaries becomes the new primary
Read Operations
When a replica set has one and only one primary, reads from that primary provide strict consistency. By default,
clients read fromthe primary;however, clients can specify a read preferenceto send read operations to secondaries.
Asynchronous replication to secondaries means that reads from secondaries may return data that does not reflect
the state of the data on the primary.This is called eventual consistency.The time that lapses between secondary to
get synchronized with primary is called replication lag. Regardless of write concern, other clients can see the result
of the write operations before the write operation is acknowledged to the issuingclient. Clients can read data which
may be subsequently rolled back.

Deploying a REPLICA set
Procedure
The following procedure outlines the steps to deploy a replica set when access control is disabled.
1) Start each member of the replica set with the appropriate options.
For each member, start a mongod and specify the replica set name through the replSet option. Specify any other
parameters specific to your deployment. If your application connects to more than one replica set, each set should
have a distinct name. Some drivers group replica set connections by replica set name.
The following example specifies the replica set name through the --replSet command-line option:
mongod --replSet "rs0"
mongod --dbpath D:data --replSet rs0 --port 27017
2) Connect a mongo shell to a replica set member.For example, to connect to a mongod runningon localhost
on the default port of 27017, simply issue: mongo
3) Initiate the replica set. Use rs.initiate() on the replica set member:
MongoDB initiates a set that consists of the current member and that uses the default replica set configuration.
4) Verify the initial replica set configuration.
Use rs.conf() to display the replica set configuration object: rs.conf()
The replica set configuration object resembles the following:
{ "_id" : "rs0", "version" : 1, "members" : [ {"_id" : 1 , "host" : "mongodb0.example.net:27017" } ] }
5) Add the remaining members to the replica set.
Add the remaining members with the rs.add() method. The following example adds two members:
rs.add("localhost:27017")
rs.add("10.0.1.128:27017")

When complete, you have a fully functional replica set. The new replica set will elect a primary.
6) Use the rs.status() operation: rs.status()
For More information regarding Replication please refer http://docs.mongodb.org/manual/core/replication/
Replica set deployment screenshots
1) On same machine starting two mongod services with different ports

2) On other machine starting mongod service with different port number
3) Connect to any of the running mongod instance and then add the hosts and ip addresses of replica set
members to a config variable as shown below and initiate replica set using rs.initiate() method.

4) Check the status of the replica set using the following command
rs.status()
Thus a replica set is successfully deployed.

Sharding:
Sharding is a method for storing data across multiple machines. MongoDB uses sharding to support
deployments with very large data sets and high throughput operations.
PurposeofSharding:Database systems with large data sets and high throughput applications can challenge
the capacity of a single server. High query rates can exhaust the CPU capacity of the server. Larger data sets
exceed the storage capacity of a single machine. Finally, working set sizes larger than the system’s RAM stress
the I/O capacity of disk drives.
To address these issues of scales, database systems have two basic approachesand those are vertical scaling
and sharding.
Vertical scaling adds more CPU and storage resources to increase capacity. Scaling by adding capacity has
limitations: high performance systems with large numbers of CPUs and large amount of RAM are
disproportionately more expensive than smaller systems. Additionally, cloud-based providers may only allow
users to provision smaller instances. As a result there is a practical maximum capability for vertical scaling.
Sharding, or horizontal scaling, by contrast, divides the data set and distributes the data over multiple servers,
or shards. Each shard is an independent database, and collectively, the shards make up a single logical
database.
Sharding addresses the challenge of scaling to support high throughput and large data sets:
1) Sharding reduces the number of operations each shard handles. Each shard processes fewer
operations as the cluster grows. As a result, a cluster can increase capacity and throughput
horizontally.
For example, to insert data, theapplication only needs to access theshard responsible for that record.

2) Sharding reduces the amount of data that each server needs to store. Each shard stores less data as
the cluster grows.
For example, if a database has a 1 terabyte data set, and there are 4 shards, then each shard might
hold only 256GB of data. If there are 40 shards, then each shard might hold only 25GB of data.
Sharding in MongoDB
MongoDB supports sharding through the configuration of a sharded clusters.
Diagram of a sample sharded cluster for production purposes. Contains exactly 3 config servers, 2 or more
``mongos`` query routers, and at least 2 shards. The shards are replica sets.
Sharded cluster has the following components: shards, query routers and config servers.
1) Shards store the data. To provide high availability and data consistency, in a production sharded
cluster, each shard is a replica set [1]. For more information on replica sets, see Replica Sets.
2) Query Routers, or mongos instances, interface with client applications and direct operations to the
appropriate shard or shards. The query router processes and targets operations to shards and then
returns results to the clients. A sharded cluster can contain more than one query router to divide the

client request load. A client sends requests to one query router. Most sharded clusters have many
query routers.
3) Config servers store the cluster’s metadata. This data contains a mapping of the cluster’s data set to
the shards. The query router uses this metadata to target operations to specific shards. Production
sharded clusters have exactly 3 config servers.
Note: For development and testing purposes only, each shard can be a single mongod instead of a replica set.
Do not deploy production clusters without 3 config servers.
Deploy a Sharded Cluster
Use the following sequence of tasks to deploy a sharded cluster:
WARNING
If you use either “localhost” or 127.0.0.1 as the hostname portion of any host identifier, for example as the
host argument to addShard or the value to the --configdb run time option, then you must use “localhost” or
127.0.0.1 for all host settings for any MongoDB instances in the cluster. If you mix localhost addresses and
remote host address, MongoDB will error.
Start the Config Server Database Instances
The config server processes are mongod instances that store the cluster’s metadata. You designate a mongod
as a config server using the --configsvr option. Each config server stores a complete copy of the cluster’s
metadata.
In production deployments, you must deploy exactly three config server instances, each running on different
servers to assure good uptime and data safety. In test environments, you can run all three instances on a single
server.
IMPORTANT
All members of a sharded cluster must be able to connect to all other members of a sharded cluster, including
all shards and all config servers. Ensure that the network and security systems including all interfaces and
firewalls, allow these connections.

Create data directories for each of the three config server instances. By default, a config server stores its data
files in the /data/configdb directory.
Start the three config server instances. Start each by issuing a command using the following syntax:
mongod --configsvr --dbpath <path> --port <port>
The default port for config servers is 27019. You can specify a different port. The following example starts a
config server using the default port and default data directory:
mongod --configsvr --dbpath /data/configdb --port 27019
For additional command options, see mongod or Configuration File Options.
NOTE: All config servers must be running and available when you first initiate a sharded cluster.
Start the mongos Instances
The mongos instances are lightweight and do not require data directories. You can run a mongos instance on
a system that runs other cluster components, such as on an application server or a server running a mongod
process. By default, a mongos instance runs on port 27017.When you start the mongos instance, specify the
hostnames of the three config servers, either in the configuration file or as command line parameters.
NOTE : To avoid downtime, give each config server a logical DNS name (unrelated to the server’s physical or
virtual hostname). Without logical DNS names, moving or renaming a config server requires shutting down
every mongod and mongos instance in the sharded cluster.
To start a mongos instance, issue a command using the following syntax:
mongos --configdb <config server hostnames>
For example, to start a mongos that connects to config server instance running on the following hosts and on
the default ports:
cfg0.example.net
cfg1.example.net

cfg2.example.net
You would issue the following command:
mongos --configdb cfg0.example.net:27019,cfg1.example.net:27019,cfg2.example.net:27019
Each mongos in a sharded cluster must use the same configDB string, with identical host names listed in
identical order. If you start a mongos instance with a string that does not exactly match the string used by the
other mongos instances in the cluster, the mongos return a Config Database String Error error and refuse to
start.
Add Shards to the Cluster
A shard can be a standalone mongod or a replica set. In a production environment, each shard should be a
replica set. Use the procedure in Deploy a Replica Set todeploy replica sets for eachshard.From a mongo shell,
connect to the mongos instance.
Issue a command using the following syntax:
mongo --host <hostname of machine running mongos> --port <port mongos listens on>
For example, if a mongos is accessible at mongos0.example.net on port 27017, issue the following command:
mongo --host mongos0.example.net --port 27017
Add each shard to the cluster using the sh.addShard() method, as shown in the examples below. Issue
sh.addShard() separately for each shard. If the shard is a replica set, specify the name of the replica set and
specify a member of the set. In production deployments, all shards should be replica sets.
OPTIONAL
You can instead use the addShard database command, which lets you specify a name and maximum size for
the shard. If you do not specify these, MongoDB automatically assigns a name and maximum size. To use the
database command, see addShard.
The following are examples of adding a shard with sh.addShard():

To add a shard for a replica set named rs1 with a member running on port 27017 on mongodb0.example.net,
issue the following command:
sh.addShard( "rs1/mongodb0.example.net:27017" )
To add a shard for a standalone mongod on port 27017 of mongodb0.example.net, issue the following
command:
sh.addShard( "mongodb0.example.net:27017" )
NOTE: It might take some time for chunks to migrate to the new shard.
Enable Sharding for a Database
Before you can shard a collection, you must enable sharding for the collection’s database. Enabling sharding
for a database does not redistribute data but make it possible to shard the collections in that database.Once
you enable sharding for a database, MongoDB assigns a primary shard for that database where MongoDB
stores all data before sharding begins.
From a mongo shell, connect to the mongos instance. Issue a command using the following syntax:
mongo --host <hostname of machine running mongos> --port <port mongos listens on>
Issue the sh.enableSharding() method, specifying the name of the database for which to enable sharding. Use
the following syntax:
sh.enableSharding("<database>")
Optionally, you can enable sharding for a database using the enableSharding command, which uses the
following syntax:
db.runCommand( { enableSharding: <database> } )
Shard a Collection
You shard on a per-collection basis.

Determinewhat you will use for theshard key. Your selection of the shard key affects the efficiency of sharding.
See the selection considerations listed in the Considerations for Selecting Shard Key.
If the collection already contains data you must create an index on the shard key using createIndex(). If the
collection is empty then MongoDB will create the index as part of the sh.shardCollection() step.
Shard a collection by issuing the sh.shardCollection() method in the mongo shell. The method uses the
following syntax:
sh.shardCollection("<database>.<collection>", shard-key-pattern)
Replace the <database>.<collection> string with the full namespace of your database, which consists of the
name of your database, a dot (e.g. .), and the full name of the collection. The shard-key-pattern represents
your shard key, which you specify in the same form as you would an index key pattern.
EXAMPLE
The following sequence of commands shards four collections:
sh.shardCollection("records.people", { "zipcode": 1, "name": 1 } )
sh.shardCollection("people.addresses", { "state": 1, "_id": 1 } )
sh.shardCollection("assets.chairs", { "type": 1, "_id": 1 } )
sh.shardCollection("events.alerts", { "_id": "hashed" } )
In order, these operations shard:
The people collection in the records database using the shard key { "zipcode": 1, "name": 1 }.
This shard key distributes documents by the value of the zipcode field. If a number of documents have the
same value for this field, then that chunk will be splittable by the values of the name field.
The addresses collection in the people database using the shard key { "state": 1, "_id": 1 }.
This shard key distributes documents by the value of the state field. If a number of documents have the same
value for this field, then that chunk will be splittable by the values of the _id field.
The chairs collection in the assets database using the shard key { "type": 1, "_id": 1 }.
This shard key distributes documents by the value of the type field. If a number of documents have the same
value for this field, then that chunk will be splittable by the values of the _id field.
The alerts collection in the events database using the shard key { "_id": "hashed" }.
This shard key distributes documents by a hash of the value of the _id field. MongoDB computes the hash of
the _id field for the hashed index, which should provide an even distribution of documents across a cluster.

The Screenshots of the above procedure are tagged here for better understanding. The commands were
highlighted for easy reference of the commands used.
1) Starting three mongod instances with configsvr option and different ports

After starting three mongod instances they should be added to a shard as follows
2)
The full command that is used is
mongos --configdb 10.0.1.128:27017, 10.0.1.128:27018, 10.0.1.128:27019 --port 27020
Now it’stime for deploying replica set. Theprocedure of deploying with screenshots is already discussed above.
Even though for better idea screenshots of all steps added for reader convenience.
2) Using the highlighted command with –shardsvr option mongod instance is started.

MongoDB Replication and Sharding

The configuration for adding mongod instances is defined to a variable called config and replica set is deployed
with rs.initiate(config) command. Check rs.status() for the replica set status.
Thus a replica set is also deployed and is now ready to be added to a shard.
Following are the screenshots involved in adding a replica set members to a shard.

Now mongo is connected to shard server running on port 27020 and is checked for sh.status() for shard status.
With sh.addShard() command the replica set rs0 is added to the shard as shown in the screenshot below.
Thus all the members of replica set rs0 areadded to theshard. Similarly add more replica sets to start sharding
onto multiple servers. Now you can enable sharding to any database and any collection using the following
commands
1) sh.enableSharding(database)
2) sh.shardCollection(“collection name”,{key:1})
For more information on replication and sharding checkout the following links
http://docs.mongodb.org/v3.0/core/replication-introduction/
http://docs.mongodb.org/v3.0/core/sharding-introduction/

MongoDB Replication and Sharding

Recommended

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to MongoDB Replication and Sharding (20)

MongoDB Replication and Sharding