• Mongodb Shell Commands Cheat Sheet Free
• Mongodb Command Line Commands
• Mongodb Shell Commands Cheat Sheet Download
• Mongodb Command Line

As part of our MongoDB Guide, we’ve compiled this cheat sheet of common and not-so-common MongoDB commands. (This article is part of our MongoDB Guide. Use the right-hand menu to navigate.) Table of Contents. Pretty Print Create Collection Create Indexes Create index Create sparse index Create compound index Create geo index Create partial index. Tip: You can specify the database to use when launching the shell by adding the name of the database as first parameter. Tip: If you are stuck in the shell a good starting point is the help command. Run a command from the regular shell. Sometimes it’s convenient to run a command directly from the regular shell. MongoDB Commands Listing (Common Line Options): There are numerous options provided by MongoDB but in this section, let us discuss the most common options of MongoDB when used in conjunction with the MongoDB shell startup, to work with MongoDB database server seamlessly.

The Cheat Sheet. Start your MongoDB Daemon. You need Mongo running before you can run the Mongo Shell or interact with Mongo in any way. Start the MongoDB Shell. If you want to interact with Mongo through the command line this is how you’ll do it.

MongoDB is a popular NoSQL database that allows unauthenticated access by default.

Regardless of the user’s authentication database, Mongo always stores user information in admin.

MongoDB stores all user information, including name, password, and the user’s authentication database, in the system.users collection in the admin database.

See centralized-user-data and system-users-collection.

When you create a user and grant that user access to a single database (aka their authentication database) then that information can only be stored in the admin database.

So, it’s not really a question of “best practice”; storing user details in admin is MongoDB’s choice, as implemented by their user management commands.

Update in response to this comment:

Ok, so the users are always located in the admin db, but I may also add “duplicates” to the other dbs? Maybe the question should be whether there any advantage in adding users to the other “non admin” dbs?

If you intend to have a single user with access to multiple databases then create a single user with roles in each of those databases rather than creating that user multiple times i.e. once in each of those databases. For example:

Create initial admin user

Sharded Cluster with enforced authentication

Create:

• a cluster-wide admin user
• a replica set specific admin user

Cluster-wide Admin

Replica Set Admin (a.k.a shard local)

Enable authentication in the mongos configuration

Connect to all replica set member nodes

Authenticate and check that the admin users exist

Log in

Rename collections

Copy Collection

Check replication set status

Backup/Restore

Documents

Admin commands

TLS 1.2 for Mongo Routers

To protect your application’s database connection enable TLS on the mongo routers as follows. Note that your mongo driver configuration needs to trust the CA certificate and enable transport encryption with ssl=true.

Rolling Update/Cluster Patching

Maintenance (startup in reverse order):

Replication Concept

1. write operations go to the primary node
2. all changes are recorded into operations log
3. asynchronous replication to secondary
4. secondaries copy the primary oplog
5. secondary can use sync source secondary*

• automatic failover on primary failure

*settings.chainingAllowed (true by default)

Replica set oplog

• special capped collection that keeps a rolling record of all operations that modify the data stored in the databases
• idempotent

• default oplog size (for Unix and Windows systems):

  Storage Engine	Default Oplog Size	Lower Bound	Upper Bound
  In-memory	5% of physical memory	50MB	50GB
  WiredTiger	5% of free disk space	990MB	50GB
  MMAPv1	5% of free disk space	990MB	50GB

Deployment

• start each server with config options for replSet
  /usr/bin/mongod --replSet 'myRepl'
• initiate the replica set on one node - rs.initialize()
• verify the configuration - rs.conf()
• add the rest of the nodes - rs.add() on the primary node
  rs.add('node2:27017') , rs.add('node3:27017')
• check the status of the replica set - rs.status()

Sharding

Components

• shard/replica set - subset of the sharded data
• config servers - metadata and config settings
• mongos - query router, cluster interface
  sh.addShard('shardName')

Shards

Mongodb Shell Commands Cheat Sheet Free

• contains subset of sharded data
• replica set for redundancy and HA with odd number of voting members
• primary shard
• don’t shard collections if dataset fits into single server
• –shardsvr in config file (port 27018)
• every xxx has a primary shard per database
• all non-shared collections will reside on primary shard

Shard keys (and limitations)

• shard keys are immutable with max size of 512 bytes (can not be updated/changed)
• must be ascending indexed key or indexed compound keys that exists in every document in the collection
• cannot be multikey index, a text index or a geospatial index
• update operations that affect a single document must include the shard key or the _id field
• no option for sharding if unique indexes on other fields exist
• no option for second unique index if the shard key is unique index
• ranged sharding may not distribute the data evenly
• hashed sharding distributes the data randomly

Config servers

• config servers as replica set (only 3.4)
• stores the metadata for sharded cluster in config database
• authentication configuration information in admin database
• holds balancer on Primary node (>= 3.4)
• –configsvr in config file (port 27019)

mongos

• caching metadata from config servers
• routes queries to shards
• no persistent state
• updates cache on metadata changes
• holds balancer (mongodb <= 3.2)
• mongos version 3.4 can not connect to earlier mongod version

Sharding collection

Step	Command
Enable sharding on database	sh.enableSharding('users')
Shard collection	sh.shardCollection('users.history', { user_id : 1 } )
Shard key - indexed key that exists in every document	range based sh.shardCollection('users.history', { user_id : 1 } ) hashed based sh.shardCollection( 'users.history', { user_id • 'hashed' } )

output

Mongodb Command Line Commands

markdown source

Description	Command
Show All Databases	show dbs
Show Current Database	db
Create Or Switch Database	use acme
Drop	db.dropDatabase()
Create Collection	db.createCollection('posts')
Show Collections	show collections
Get All Rows	db.posts.find()
Get All Rows Formatted	db.find().pretty()
Find Rows	db.posts.find({ category: 'News' })
Sort Rows	asc: db.posts.find().sort({ title: 1 }).pretty() desc: db.posts.find().sort({ title: -1 }).pretty()
Count Rows	db.posts.find().count() db.posts.find({ category: 'news' }).count()
Limit Rows	db.posts.find().limit(2).pretty()
Chaining	db.posts.find().limit(2).sort({ title: 1 }).pretty()
Foreach	db.posts.find().forEach(function(doc) { print('Blog Post: ' + doc.title)})
Find One Row	db.posts.findOne({ category: 'News' })
Find Specific Fields	db.posts.find({ title: 'Post One' }, { title: 1, author: 1})
Delete Row	db.posts.remove({ title: 'Post Four' })
Add Index	db.posts.createIndex({ title: 'text' })

Insert Row¶

Insert Multiple Rows¶

Update Row¶

Update Specific Field¶

Increment Field ($inc)¶

Rename Field¶

Mongodb Shell Commands Cheat Sheet Download

Sub-Documents¶

Find By Element in Array ($elemMatch)¶

Text Search¶

Mongodb Command Line

Greater & Less Than¶