Chapter 7.

Basic Cluster Administration

1
 References
• MongoDB The Definitive Guide: Powerful and Scalable Data Storage 3rd
Edition
• https://docs.mongodb.com/
• https://www.mongodb.com/docs/manual/

2
 Contents

• Mongod
• Security
• Replication
• Sharding

3
 What is mongod?
• mongod is the main daemon process for MongoDB.
• It handles data requests, manages data access, and performs background
management operations
• We run a separate mongod process for each server.

mongod mongod mongod

4
 What is mongod?
• When we launch mongod, we're essentially starting up a new database.
But we don't interact with the mongod process directly. Instead, we use a
database client to communicate with mongod (mongo, mongosh).
• Default configuration:
o IP Binding: localhost (127.0.0.1).
o Port: 27017.
o Data directory: typically in C:\data\db on Windows systems.
o Log file: typically in C:\Program
Files\MongoDB\Server\version_number\log\mongod.log on Windows systems
o Authentication is turned off, so clients are not required to authenticate before
accessing the database.

5
 Mongod options
Example: mongod --bind_ip localhost --port 27017 --dbpath /data --logpath /log/mongod.log
• --bind_ip: specify which IP addresses mongod should bind to. When
mongod binds to an IP address, clients from that address are able to
connect to mongod.
• --port <port number>: specify the port on which mongod will listen for client
connections (command "netstat -a –n" to see used ‘host:ports’)
• --dbpath <path>: specify where all data files of database are stored.
• --logpath <path>: specify where and name log file is stored
• --auth: enables authentication to control which users can access the
database. When auth is specified, all database clients who want to connect
to mongod first need to authenticate.
• --help: output the various options for mongod with a description of their
functionality → mongod --help or mongod -h 6
 Mongod options
• Example:
Run command line as administrator:
mongod --bind_ip localhost --port 27017 --dbpath C:/"Program Files"/MongoDB/Server/5.0/data
--logpath C:/"Program Files"/MongoDB/Server/5.0/log/mongod.log

7
 Mongod – Configuration File
• Configuration file is a way to organize the options you need to run the
mongod process into an easy to parse YAML (Yet Another Markup
Language) file
mongod --dbpath data/db --logpath data/log/mongod.log --replSet 'M103' --keyFile /data/keyfile --bind_ip localhost

• Why do we need to use configuration file?

Command Line Options Configuration File Option
--bind_ip net.bind_ip
--port net.port
--dbpath storage.dbPath
--logpath systemLog.path and systemLog.destination
--replSet replication.replSetName
--keyFile security.keyFile
… …

8
 Mongod – Configuration File
YAML file
Configuration File Option
storage.dbPath

systemLog.path
systemLog.destination

net.bind_ip
net.port

security.keyFile

replication.replSetName

Launch mongod with the --config command line option:

mongod --config 'd:\CSDL_NoSQL\config_files\mongod.cfg'

9
 Mongod – An example
• Run a mongod instance with custom configuration:
o Create configuration file with port 27000, any dbpath and logpath;
o Start a mongod with the configuration file;
o Start a mongo and connect to that mongod;
o View databases…

10
 Mongod – Basic Commands
• Cover a few of the basic commands necessary to interact with the
MongoDB cluster.
• These methods are available in the mongodb shell that wrap underlying
database commands.
o db.<method>(): DB shell helpers, interact with the database.
✓db.<collection>.<method>(): shell helpers for collection level operations.
o rs.<method>(): rs helper methods, control replica set deployment and
management.
o sh.<method>(): sh helper methods, control sharded cluster deployment and
management.
o (Read More)

11
 Mongod – Basic Commands
• User management, example:
o db.createUser()
o db.dropUser()
• Collection management, example :
o db.<collection>.renameCollection( <target>, <dropTarget> ) [dropTarget:
optional]
o db.<collection>.createIndex( <keys>, <options>, <commitQuorum> )
o db.<collection>.drop( <options> )
• Database management, example:
o db.dropDatabase( <writeConcern> ) [removes current database]
o db.createCollection( <name>, <options> )
• Database status, example:
12
o db.serverStatus()
 Contents

• Mongod
• Security
• Replication
• Sharding

13
 Basic Security
• How do we secure the data?
Authentication Authorization
• Verifies the identity of a user • Verifies the priviliges of a user
• Answers the question : Who are you? • Answers the question: What do you have
access to?

• SCRAM: default and most basic • Each user has one or more Roles.
form of client authentication • Each Role has one or more Privileges.
(password security)
• A Privilege represent a group of actions
• X.509: certificate for authentication, and the resources that those actions
more secure and more complex apply to.
• LDAP
Only for MongoDB Enterprise
• Kerberos

14
 Basic Security
• Authorization: Role-based access control
o Roles support a high level of responsibility isolation for operational task:

✓To enable role-based access control or authorization on cluster: enable

authorization in configuration file.
✓By default, MongoDB doesn't give you any users.
✓Always create a user with the administrative role first so you can create other
users after.
#enable security
security:
authorization: enabled
15
 Basic Security
• Localhost exception:
o Allows you to access a MongoDB server that enforces authentication but does
not yet configured user for you to authenticate with.
o Must run mongo/mongosh from the same host running MongoDB server.
• Localhost exception closes after you create your first user.
• Always create a user with administrative privileges first (userAdmin or
userAdminAnyDatabase roles).
db.createUser {
user: "<name>",
pwd: passwordPrompt(), // Or "<cleartext password>"
customData: { <any information> },
roles: [ { role: "<role>", db: "<database>" } | "<role>", ... ]
} 16
 Basic Security
• Roles structure:
o A role is composed of:
✓Set of privileges that role enables
✓Privilege defines the action, or actions, that can be performed over a resource
✓Resources:
• Database
• Collection or set of collections
• Cluster: Replica set, Shard cluster
{resource: {cluster: true}, action: ['shutdown']}
A role with privilege, allowed to shut down any member of the cluster

17
 Basic Security
• Roles in MongoDB:
o Build-In roles: pre-packaged MongoDB roles.
o Custom roles: tailored roles to attend specific needs of specific users.

18
 Basic Security
• Build-In roles
Role levels Roles
Database Users read, readWrite
Database Administration userAdmin, dbAdmin
clusterAdmin, clusterManager, clusterMonitor,
Cluster Administration
hostManager
Backup and Restore backup, restore
Super User root (root is also a role at the all database level)
readAnyDatabase, readWriteAnyDatabase
AllDatabase
dbAdminAnyDatabase, userAdminAnyDatabase
(read more Built-In Roles)

19
 Basic Security
Example:
Run MongoDB server that enforces authentication (no user created):
mongod --config 'D:\HeQTCSDL_NoSQL\config_files\mongod.conf'

Run mongosh from the same host running MongoDB server:

mongosh --host 127.0.0.1:27017

Create your first user:

use admin
db.createUser( { user : 'root', pwd : 'root', roles : ['root'] })
Exit mongosh then run again with 'root' user:
mongosh --port 27017 -u root -p root --authenticationDatabase admin
or mongosh admin -u root -p root
20
 Basic Security
• Build-In Roles: userAdmin
o Allows user to do all operations around user management. Not able to do anything related
with data management or data modifications.
o Provides the ability to create and modify roles and users on the current database. Since the
userAdmin role allows users to grant any privilege to any user, including themselves, the role
also indirectly provides super-user access to either the database or, if scoped to the admin
database, the cluster. (read more userAdmin role)
Example:
- Run mongod with config file:
mongod --config 'D:\mongod.conf’
- Run mongosh to connect to MongoDB server with root user:
mongosh admin -u root -p root
- Create securityUser and grant userAdmin role
use admin //all user should be created on the database admin for simplicity reasons
db.createUser( { user : 'securityUser', pwd : '123', roles : [ { db : 'admin', role : 'userAdmin' } ] } )
21
 Basic Security
• Build-In Roles: dbAdmin
o Provides the ability to perform administrative tasks such as schema-related tasks,
indexing, and gathering statistics. This role does not grant privileges for user and role
management.
o Everything that is related with DDL (data definition language), this user will be able to perform.
o Everything that is related with the DML (data modification language) operations, he will not be
able to do. (read more dbAdmin role)
Example:
- Create securityUser and grant dbAdmin role:
use admin
db.createUser( { user : 'DBAcourse', pwd : '123', roles : [ { db : 'mongoCourse', role : 'dbAdmin' } ] } )
//in this case, the roles of dbAdmin only be granted to mongoCourse db.
- Roles can vary between databases. We can have a given user with different roles on a per database basis:
db.grantRolesToUser( 'DBAcourse', [ { db : 'reporting', role : 'dbOwner' } ] )
dbOwner role as a meta role. This role combines the privileges granted by the readWrite, dbAdmin,
userAdmin roles 22
 An example with security
1. Create configuration file with port 27000, any dbpath, logpath and enable
authorization in configuration file;
2. Start a mongod with the configuration file;
3. Start a mongo and connect to that mongod;
4. Create a user with the userAdmin or userAdminAnyDatabase role;
5. Exit mongo and then run again with the user just created;
6. View database, create database, createCollection…
7. Create another user with the read role on ‘demo’ database
8. Create another user with the readWrite role on ‘demo’ database
9. Exit mongo and then run again with the user with read/readWrite role. View
what can do with the roles.

23
 Contents

• Mongod
• Security
• Replication
• Sharding

24
 Replication
• Replication: Maintain multiple copies of your data – Really important
• Why?
o Can never assume all servers will always be available
o To make sure, if server goes down, you can still access your data 
Redundancy and Data Availability
o Replication can provide increased read capacity as clients can send read
operations to different servers
o If the database is hosted on a single server  standalone node

Client
Application Data

25
 Replication
• A replica set is a group of mongod instances that maintain the same data set.
• A replica set contains several data bearing nodes and optionally one arbiter node.
Of the data bearing nodes, one and only one member is deemed the primary
node, while the other nodes are deemed secondary nodes.
• A secondary can become a primary: If the current primary becomes unavailable,
the replica set holds an election to choose which of the secondaries becomes the
new primary.
• All writes are directed to the primary member whereas the secondary members
replicate from the primary asynchronously using oplog.
o The oplog (operations log) is a special capped collection that keeps a record of all
operations that modify the data stored in your databases.
o MongoDB applies database operations on the primary and then records the
operations on the primary's oplog. The secondary members then copy and apply
these operations in an asynchronous process.
(read more Replica Set)
26
 Replication
• Replica set members:
o Primary: receives all write operations
o Secondary: replicates operations from the primary to maintain an identical
data set, it can be configure for a specific purpose:
✓Priority 0 members - are secondary members that maintain the primary’s data
copy but can never become a primary in case of a failover. They can participate in
voting and can accept read requests (see Priority 0 Replica Set Members).
✓Hidden members - are 0-priority members that are hidden from the client
applications (can’t serve any read requests). (see Hidden Replica Set Members).
✓Delayed members - are secondary members that replicate data with a delay
from the primary’s oplog (see Delayed Replica Set Members).
o Arbiter: participates in elections but does not hold data

27
 Replication
Client
Application

Replica Set

Primary

Heartbeat
Secondary Secondary

three-member primary-secondary-secondary architecture 28

 Replication
(read more Replica Set Arbiter)
Client
Application

Replica Set

Primary

Heartbeat/2s Arbiter
Secondary (vote only)

three-member primary-secondary-arbiter (PSA) architecture 29

 Replication
Client
Application

Replica Set

Primary

Replication

Heartbeat
Primary
Secondary Secondary

30
 Replication
• Setting up a Replica Set
Example:

Replica Set
Primary
(27011)

Secondary Secondary
(27012) (27013)

31
 Replication
• Setting up a Replica Set:
1. Use configuration file for standalone mongod;
2. Start a mongod with configuration file;
3. Start a mongo and connect to one of mongo instance;
4. Initialize replica set;
5. Create root user;
6. Exit out of this mongo and then log back in as root user;
7. Add nodes to replica set

32
 Replication
Setting up a Replica Set:
1- Use configuration file for standalone mongod

storage: storage: storage:

dbPath: d:\mongodb\db\node1 Optional, it is used to
dbPath: d:\mongodb\db\node2 dbPath: d:\mongodb\db\node3

net:
encrypt data exchanged net:
net:
bindIp: localhost between
bindIp: client
localhost bindIp: localhost
port: 27011 application
port: 27012and mongodb port: 27013

security: security: security:

authorization: enabled authorization: enabled authorization: enabled
keyFile: d:\mongodb\pki\m-keyfile keyFile: d:\mongodb\pki\m-keyfile keyFile: d:\mongodb\pki\m-keyfile

systemLog: systemLog: systemLog:

destination: file destination: file destination: file
path: d:\mongodb\db\node1\mongod.log path: d:\mongodb\db\node3\mongod.log
path: d:\mongodb\db\node2\mongod.log
logAppend: true logAppend: true logAppend: true

replication: replication: replication:

replSetName: rep-example replSetName: rep-example replSetName: rep-example

33
 Replication
Setting up a Replica Set:
2- Start a mongod with configuration file:
mongod --config 'c:\mongoDB\configs\node1.conf’
mongod --config 'c:\mongoDB\configs\node2.conf’
mongod --config 'c:\mongoDB\configs\node3.conf’
3- Start a mongo and connect to one of mongo instance:
mongo --host localhost:27011
4- Initialize replica set:
rs.initiate()
5- Create root user:
use admin
db.createUser({ user: 'm-admin', pwd: 'm-pass', roles: [ { role : 'root', db : 'admin' } ] })

34
 Replication
Setting up a Replica Set
6- Exit out of this mongo and then log back in as m-admin user
mongosh --host rep-example/localhost:27011 -u m-admin -p m-pass --authenticationDatabase admin
7- Add nodes to Replica set Replica set name
rs.add( 'localhost:27012' )
rs.add( 'localhost:27013' )

To check status of Replica set: rs.status()

To check if the current node is primary: rs.isMaster()

35
 Replication
• Replication Configuration Document:
o The replica set configuration document is a simple BSON document that we
manage using a JSON representation
o Can be configured from the shell
o There are set of mongo shell replication helper methods that make it easier to
manage
✓rs.initiate() : Initializes a new replica set.
✓rs.add() : Adds a member to a replica set.
✓rs.addArb() : Adds an arbiter to a replica set.
✓rs.remove() : Remove a member from a replica set.
✓rs.reconfig() : Reconfigures a replica set by applying a new replica set
configuration object.
✓… (seft study)
36
 Replication
• Reconfiguring a Running Replica Set:

Replica Set

Primary Secondary
(node 1) (node 4)

Arbiter
Secondary Secondary (node 5)
(node 2) (node 3)

37
 Replication
Reconfiguring a Running Replica Set:
1- Create config files for the secondaries 3 and arbiter nodes

storage: storage:
dbPath: d:\mongodb\db\node4 dbPath: d:\mongodb\db\arbiter
net: net:
bindIp: localhost bindIp: localhost
port: 27014 port: 28000
security: security:
authorization: enabled authorization: enabled
keyFile: d:\mongodb\pki\m-keyfile keyFile: d:\mongodb\pki\m-keyfile
systemLog: systemLog:
destination: file destination: file
path: d:\mongodb\db\node4\mongod.log path: d:\mongodb\db\arbiter\mongod.log
logAppend: true logAppend: true
replication: replication:
replSetName: rep-example replSetName: rep-example

38
 Replication
Replica Set
Reconfiguring a Running Replica Set:
Primary

2- Starting up mongod processes for our fourth node and arbiter (node 1)

mongod --config 'c:\mongoDB\configs\node4.conf’ Secondary

(node 2)
Arbiter
(node 5)

mongod --config 'c:\mongoDB\configs\arbiter.conf’

Secondary Secondary

3- Run Mongo shell and connect to the replica set m-example (node 3) (node 4)

mongo --host m-example/localhost:27011 -u 'm-admin' -p 'm-pass'

--authenticationDatabase 'admin’
4- From the Mongo shell of the replica set, adding the new secondary
and the new arbiter:
rs.add( 'localhost:27014’ )
rs.addArb( 'localhost:28000’ )
5- Checking replica set make up after adding two new nodes:
rs.isMaster()

39
 Replication
Reconfiguring a Running Replica Set:
- Removing the arbiter from our replica set:
rs.remove( 'localhost:28000’ )
- Assigning the current configuration to a shell variable we can edit, in order to reconfigure the
replica set:
cfg = rs.conf()
- Editing our new variable cfg to change topology - specifically, by modifying cfg.members:
cfg.members[3].votes = 0
cfg.members[3].hidden = true
cfg.members[3].priority = 0
- Updating our replica set to use the new configuration cfg:
rs.reconfig( cfg )

40
 Replication
• Failover and Elections:
o Primary node is the first point where the client application accesses the
database.
o If secondaries go down, the client will continue communicating with the node
acting as primary until the primary is unavailable.
Replica Set
Client
Primary Application

Secondary Secondary
41
 Replication
• Failover and Elections:
o What would cause a primary to become unavailable? → a common reason is
maintenance.
Replica Set
? Client
Primary Application

Secondary Secondary

42
 Replication
• Failover and Elections:
o Let's say we want to roll upgrade on a three nodes replica set.
o A rolling upgrade just means we're upgrading one server at a time, starting
with the secondaries and eventually, we'll upgrade the primary.
upgrade to
Replica Set version 5.0

Primary
(node1 - v4.2)

Secondary Secondary
(node2 - v4.2) (node3 - v4.2)

43
 Replication
• Failover and Elections:

Replica Set

Primary
(node1 –- v4.2)
(node2 v5.0)

Secondary Secondary
(node2–––-v5.0)
(node1
(node2
(node1 v4.2)
v4.3)
v5.0) (node3 –- v4.2)
(node3 v5.0)

44
 Contents

• Mongod
• Security
• Replication
• Sharding

45
 Sharding
• What is Sharding?
o In a replica set, we have more than one server in
our database and each server has to contain
the entire dataset
o What do we do when the data grows, and the
servers can't work properly?

Vertical Scaling: increase the capacity of individual server:

More RAM
• Potentially become very expensive
More disk space
• Cloud-based providers aren't going to let us
More powerful CPU scale vertically forever
Horizontal Scaling: involves dividing the system dataset and load over
multiple servers, adding additional servers to increase capacity as required
46
 Sharding
50 passengers want to travel
from SG to HN at same time.
But there is only one bus with
capacity of 25 passengers

Scale out Scale up

Two buses – Total Single bus – Passenger

Passenger capacity 50 capacity 50
Horizontal Scaling Vertical Scaling
47
 Sharding
• What is Sharding?
o MongoDB, scaling is done horizontally
o The way we distribute data across multiple machines is called Sharding
o To guarantee high availability in our Sharded Cluster, we deploy each shard as
a replica set

Shard-1 Shard-2 Shard-3 Read more Sharding

(replica set) (replica set) (replica set)

48
 Sharding
• Primary Shard
o In the sharded cluster, we have the primary shard.
o All the non-sharded collections on that database will remain on primary shard
(not all the collections in a sharded cluster need to be distributed).

Primary

Sharded Non-Sharded

Shard 1 Shard 2 Shard 3

49
 Sharding
• Sharded Cluster Components:
o shard: Each shard contains a subset of the sharded data. Each shard must be
deployed as a replica set.
o mongos: The mongos acts as a query router, providing an interface between
client applications and the sharded cluster.
o config servers: Config servers store metadata and configuration settings for
the cluster. As of MongoDB 3.4, config servers must be deployed as a replica
set (CSRS - Config Server Replica Set).

50
 Sharding
Sharding Architecture Mongos routes client queries
to the correct shards

Router
client (mongos) config servers stores the
Config
collection of metadata
Server
(replica
set)

...

Shard-1 Shard-2 Shard-3

(replica set) (replica set) (replica set) 51
 Sharding
Sharding example: We split collection of football player data on the last name of each
player
Router
client (mongos)

Config Shard Data

Lastname: Server 1 A-J
(replica
Smith 2 K-Q
set)
Lastname: 3 R-Z
Ben

Shard-1 Shard-2 Shard-3 52

 Sharding
• A common sharded cluster architecture used in production:

53
 Sharding
• Setting up a Sharded Cluster:

server-04
server-01
server-02

server-05 server-03

server-06
server-07 54
 Sharding
• Setting up a Sharded Cluster:
o Build config servers:
1. Create configuration file for config servers;
2. Starting the config servers;
3. Run mongo shell and connect to one of the config servers;
4. Initiating the CSRS (Config Server Replica Set);
5. Creating super user on CSRS;
6. Authenticating as the super user;
7. Add the second and third node to the CSRS replica set;
o Config and run mongos:
o Config shard.
o Adding shards to cluster from mongos.

55
 Sharding
Setting Up a Sharded Cluster:
✓ Build config servers:
1. Create configuration file for config servers:
storage: storage: storage:
dbPath: d:\db\ShardCluster\csrs1 dbPath: d:\db\ShardCluster\csrs2 dbPath: d:\db\ShardCluster\csrs3

net: net: net:

bindIp: localhost bindIp: localhost bindIp: localhost
port: 26001 port: 26002 port: 26003

security: security: security:

authorization: enabled authorization: enabled authorization: enabled
keyFile: d:\db\pki\keyfile keyFile: d:\db\pki\keyfile keyFile: d:\db\pki\keyfile

systemLog: systemLog: systemLog:

destination: file destination: file destination: file
path: d:\db\ShardCluster\csrs2\mongod.logpath: d:\db\ShardCluster\csrs3\mongod.log
path: d:\db\ShardCluster\csrs1\mongod.log
logAppend: true logAppend: true logAppend: true

replication: replication: replication:

replSetName: configsvr-rs replSetName: configsvr-rs replSetName: configsvr-rs
sharding: sharding: sharding:
clusterRole: configsvr clusterRole: configsvr clusterRole: configsvr
csrs1.cfg csrs2.cfg csrs3.cfg
56
 Sharding
Setting Up a Sharded Cluster:
✓ Build config servers
2. Starting the config servers:
mongod --config csrs1.cfg
mongod --config csrs2.cfg
mongod --config csrs3.cfg
3. Run mongo shell and connect to one of the config servers:
mongo --port 26001
4. Initiating the CSRS (from mongo shell):
rs.initiate()
5. Creating super user on CSRS (from mongo shell):
use admin
db.createUser( { user : ‘m-admin’, pwd : 'm-pass’, roles : [ { role : 'root', db : 'admin’ } ] } )
6. Authenticating as the super user (from mongo shell)):
db.auth( 'm-admin’ , 'm-pass’ )
7. Add the second and third node to the CSRS replica set:
use admin
rs.add( 'localhost:26002’ )
rs.add( 'localhost:26003’ ) 57
 Sharding
Setting Up a Sharded Cluster:
✓ Config and run Mongos:
1. Start the mongos server:
mongos --config mongos.cfg
2. Run mongo shell and connect to mongos:
mongo --port 26000 --username m-admin --password m-pass --authenticationDatabase admin
3. Check sharding status:
net:
sh.status() bindIp: localhost
port: 26000

security:
authorization: enabled
keyFile: d:\db\pki\keyfile

systemLog:
destination: file
path: d:\db\mongos.log
logAppend: true

sharding:
configDB: configsvr-rs/localhost:26001, localhost:26002, localhost:26003

mongos.cfg 58
 Sharding
Setting Up a Sharded Cluster:
✓ Config Shard
storage: storage: storage:
dbPath: d:\db\ShardCluster\node1 dbPath: d:\db\ShardCluster\node2 dbPath: d:\db\ShardCluster\node3
wiredTiger: wiredTiger: wiredTiger:
engineConfig: engineConfig: engineConfig:
cacheSizeGB: .25 cacheSizeGB: .25 cacheSizeGB: .25
net: net: net:
bindIp: localhost bindIp: localhost bindIp: localhost
port: 27011 port: 27012 port: 27013
security: security: security:
authorization: enabled authorization: enabled authorization: enabled
keyFile: d:\db\pki\keyfile keyFile: d:\db\pki\keyfile keyFile: d:\db\pki\keyfile
systemLog: systemLog: systemLog:
destination: file destination: file destination: file
path: d:\db\ShardCluster\node1\mongod.log path: d:\db\ShardCluster\node3\mongod.log
path: d:\db\ShardCluster\node2\mongod.log
logAppend: true logAppend: true logAppend: true
replication: replication: replication:
replSetName: shard1-rs replSetName: shard1-rs replSetName: shard1-rs
sharding: sharding: sharding:
clusterRole: shardsvr clusterRole: shardsvr clusterRole: shardsvr
node1.cfg node2.cfg node3.cfg 59
Read more WiredTiger Storage Engine
 Sharding
Setting Up a Sharded Cluster:
✓ Config Shard (using of Replica set m-example2)
Run mongod with corresponding config files:
mongod --config node1.cfg
mongod --config node2.cfg
mongod --config node3.cfg
Run mongo shell and connect to one of servers:
mongo --port 27011
rs.initiate()
✓ Adding new shard to cluster from mongos
sh.addShard( ‘shard1-rs/localhost:27011’ ) //if port:27011 is primary node
Check sharding status:
sh.status()

60
 Sharding
• Shard Keys:
o MongoDB uses the shard key to distribute the collection's documents across
shards. The shard key consists of a field or multiple fields in the documents.
o MongoDB divides the span of shard key values into non-overlapping ranges of
shard key values. Each range is associated with a chunk.
o MongoDB supports two sharding strategies for distributing data across
sharded clusters:

Hashed Sharding Ranged Sharding

61
 Sharding
Shard Keys: How to shard
• Use sh.enableSharding('<database>') to enable sharding for the specified database
• Use db.collection.createIndex(key) to create index for shard key
• Use sh.shardCollection('<database>', ‘<collection>’, { shard key }) to shard collection

62
Question?

63