Skip to end of metadata
Go to start of metadata

Please be advised: As of June 1, 2016, Scalr has deprecated support for MongoDB Automated Roles.

About MongoDB 

MongoDB (from "humongous") is an open source document-oriented NoSQL database system. It makes part of the "new" NoSQL family of database systems. Instead of storing data in tables as is done in a "classical" relational database, MongoDB stores structured data as JSON-like documents with dynamic schemas (MongoDB calls the format BSON), making the integration of data in certain types of applications easier and faster. Development of MongoDB began in October 2007 by 10gen. It is now a mature and feature rich database ready for production use. It is used, for example, by MTV Networks, Craigslist and Foursquare.

MongoDB Version

The MongoDB Role runs the latest 2.0.X MongoDB version.

MongoDB Roles are available under the Farm Builder (Main MenuFarms > Add Farm). If you cannot find something that suits your needs, we recommend using the Role Builder: Main MenuRoles > Add Role > Role Builder.

MongoDB Status

Scalr provides useful information about your MongoDB databases such as the password, DNS endpoints, and data bundles as they run.

To access your MongoDB Status, go to Main MenuFarms > Select your Farm > Actions Button (rightmost column) > MongoDB Status.


Please note that the MongoDB Status option will only appear as a selection in the Actions Menu for an active (running) Farm.

MongoDB Password

Scalr generates a unique password for you to connect to your application. To access this password, click on Connection Details underneath General in the MongoDB Status Panel.

MongoDB Endpoints

Under the same MongoDB Status, Scalr provides endpoints to connect your application to your database.  Information on how to use these endpoints to connect your database to your application can be found on the Connecting to the Database Endpoints page of the documentation.


Connecting to MongoDB

To connect to Mongo, the following with authorize you as database 'admin' (if you leave that out, default is 'test').

mongo admin --verbose -u scalr -p 4DXehPOUWT

Config server's port is 27019. Router listens on port 27017 (the default). Mongo itself listens on port 27018, but you can only connect to it from within the instance console.

Cluster Map

Scaling MongoDB can be done in two symmetric ways: vertically (via Replica sets) and horizontally (via Shards). The primary means to scale out with MongoDB is through Shards. Replicas are mostly for high availability and data redundancy. You can learn more about how to create Shards and Replicas for MongoDB by referring to the Scaling section of this page.


Three Actions are supplied for working with shards and clusters when using the PostgreSQL Role for your Farm. A shard or replica of each shard may be removed from the cluster by clicking on Remove Shard or Remove replica from each shard underneath Actions in the PostgreSQL Status Panel. You can also terminate an entire cluster by clicking on Shutdown cluster.

When you are terminating a cluster, Scalr terminates all Mongo nodes and servers. At the end only Config Server should remain running but without Mongo running on it. The last Server will be terminated when the Farm will be terminated. If you want to re-launch the cluster, you need Terminate the Farm and then Launch the Farm again.

Cluster Log

The Cluster Log can be used to view the log records associated with a cluster on your MongoDB databases.


Unlike MySQL, Redis or PostgreSQL, backups for MongoDB are not available within Scalr yet, mostly because of the 10gen-admitted difficulty in backing up a sharded cluster. Until we add support, we recommend you back up your data yourself, manually or assisted by the Orchestration Engine, by using a hidden replica for creating backups in replica set (since you have only one shard). See this MongoDB Page for additional information.

For creating snapshots of RAID Volumes, this is possible, and you can also use mongodump as described in this MongoDB Article.

More detailed information on MongoDB and specific behaviors for Rackspace and AWS can be found in the Scaling section of the User Reference.


Since MongoDB is clustered databases, Scaling can be accomplished in two symmetric ways: Vertically (via Replica Sets) and Horizontally (via Shards). The primary means to scale out with MongoDB is through Shards. Replicas are mostly for high availability and data redundancy. To learn more, please refer to the Scaling section of the User Reference.

Replica Sets

Replica sets are how MongoDB handles master/slave replication. It is asynchronous and adds a built-in failover and disaster recovery logic. The main difference resides in the way the primary node (the master) is selected: none of the Instances are intrinsically primary; instead, the nodes are aware of each other and the primary is elected through a clever consensus vote. Once elected, the primary processes all the writes for the Replica Set. In the event of a failover, the primary is re-elected among all the reachable nodes. The secondaries apply operations from the binary in an asynchronous manner. 

Each Replica Set is limited to 12 total nodes and 7 voting nodes. 


MongoDB supports an automated sharding (or partitioning) of the database, enabling horizontal Scaling across multiple database Servers. Data is partitioned among multiple Instances in an order-preserving manner. MongoDB then converts to a sharded cluster that automatically manages failover and routing of your queries to each partition. To learn more about shards you can visit Mongo's documentation: Shards are the best way to scale out with MongoDB.

Shard clusters include three basic components:

ShardsConfig ServersMongos Routers
These run the mongod process (the core MongoDB database process) or a Replica Set of mongod processes (see previous section). They store the data in the form of chunks (partitions of the dataset corresponding to a given range over the shard key).Processes that hold the meta data of the cluster (location and range of the different partitions or chunks). Chunk information is the main data stored by config Servers. Scalr automatically configures the config Servers on the first node (0-0) of the cluster.*Processes that route queries and balances chunks over Shards. mongos (pronounce mongo "S") are lightweight processes that can be run on any desired Server. Scalr automatically places them on the first and second node of each Shard. mongos processes do not have any persistent state: they inherit it from the config Servers.


Two Storage Types are available for your MongoDB databases. To select your storage for your MongoDB databases, go to Main MenuFarms > Select your Farm > Actions Button (rightmost column) > Configure > Click on the MongoDB Role > MongoDB Settings.

Once you have chosen your storage type and launched your Farm, you will not be able to change it unless you remove and add the MongoDB Role again. The following options will appeared greyed out on the Database Settings Tab.

Persistent Volumes

The data persists independently from the life of an instance.

Storage Engine

The screen shots used in this section are specific to AWS; however, it is important to note that Storage Engine selection names will vary depending on the chosen cloud provider. For example, the Persistent Volumes storage type is referred to as a Persistent Disk in GCE, a Cinder Volume in Rackspace and OpenStack, and as a CloudStack Block Volume in IDCF and CloudStack.

RAID Array

Redundant Array of Independent Disks (RAID) is a storage technology that combines multiple disk drive components (persistent volumes) into a logical unit. Data is distributed across the drives in one of several ways called RAID Levels. Scalr allows you to select 4 different RAID Levels, the number of volumes you want, and their respective size.

RAID Array Availability

The RAID Array storage type is not available for every cloud service provider and will only appear if it is a viable option for the provider you are using.

  • No labels