Managing Your MongoDB Deployment

Overview

When you host your MongoDB database with MongoLab, you have access to special tools and processes that help you manage routine MongoDB tasks. Some of these tasks are described here, with detailed instructions and links for further reading.

MongoDB version management

As MongoDB Inc. continues to roll out new versions of MongoDB, it’s important to keep your database up-to-date so as to take advantage of new features, bug fixes and more.

Versions currently available at MongoLab

Currently MongoLab uses MongoDB version 2.4.x as its default, but you have option of selecting other version(s). On June 26, 2013 our default MongoDB version switched from 2.2.x to 2.4.x.

Plan TypeCurrently Supported Versions
Sandbox2.4.x or 2.6.x with experimental features enabled
For-pay Shared2.2.x or 2.4.x
For-pay Dedicated2.2.x or 2.4.x

We do not yet support version 2.6.x for production use, although it is available on our Sandbox plan as an experimental option. Our stance is to wait until after a few maintenance releases have been made (e.g., 2.6.3 or 2.6.4) before we roll it out across our fleet, so as to ensure a battle-tested, production-worthy release. While this may seem conservative, our goal is to provide a quality MongoDB experience for our users. Thanks for your patience and stay tuned for more details!

How to change MongoDB versions

Not available for Sandbox databases

If you have a for-pay database, you can upgrade (or change) the version of MongoDB you are running directly from the MongoLab management portal.

Before doing so:

When you’re ready to upgrade, follow these steps:

  1. Log in to the MongoLab management portal
  2. From your account’s Home page, navigate to the deployment that will be modified
  3. Click the “Tools” tab
  4. Select the desired version in the drop-down menu that appears in the “Upgrade MongoDB version” section
  5. Click the “Upgrade to…” button!

If you have a replica set cluster with auto-failover, we will first restart your non-primary nodes (e.g., arbiter and secondary node(s)) with the new version. Then we will intentionally fail you over in order to upgrade your original primary. Finally, we will fail you back over so that your original primary is once again primary. You should experience no downtime if your drivers and client code have been properly configured for failover. It should be noted that during failover, it may take 5-30 seconds for a new member to be elected primary.

If you are on a single-node plan, your database server will be restarted which typically involves approximately 20 seconds of downtime.

Sandbox database limitations
Because our Sandbox databases are running on server processes shared by multiple users, on-demand version changes are not possible. All Sandbox plans are auto-upgraded to the latest MongoDB version we support. To run on a specific version of MongoDB, you will need to upgrade to one of our for-pay plans where you will get your own mongod server process and the flexibility of making version changes whenever you want.

Viewing and killing current operations

Available for Dedicated plans only

You may have started a blocking or resource-intensive operation that you would like to stop.

The db.currentOp() helper method in the mongo shell reports on the current operations running on the mongod instance. You may specify the true argument (i.e., db.currentOp(true)) to return a more verbose output including idle connections and system operations.

You can use the db.killOp() helper method in the mongo shell to terminate a currently running operation. To do this pass the value of the opid field as an argument to db.killOp().

Don’t hesitate to contact support@mongolab.com for help. If you have a Dedicated plan and are in an emergency situation, use the emergency email that we provided to you.

Additional reading from the MongoLab Blog: Finding and terminating long-running operations in MongoDB

Restarting your MongoDB processes

Not available for Sandbox databases

On a rare occasion, you may need to restart your server processes. If you have a for-pay database, you can do this directly from the MongoLab management portal.

  1. Log in to the MongoLab management portal
  2. From your account’s Home page, navigate to the deployment that needs to be restarted
  3. Click the “Restart server” or “Restart cluster” (the wording is different depending on your plan type) button in the header
  4. Follow the instructions in the “Warning” window to confirm the restart, then click “Restart”

If you have a replica set cluster with auto-failover, we will use MongoDB’s replSetFreeze command to ensure that your current primary remains primary during the restart. Then we will restart each of your nodes in turn. The entire process could take a few minutes, but you should only lose access to your primary for about 20 seconds.

If you are on a single-node plan, your database server will be restarted which typically involves approximately 20 seconds of downtime.

Sandbox database limitations
Because our Sandbox databases are shared by multiple users, restarting MongoDB on-demand is not possible. If you suspect a restart is required, contact support@mongolab.com.

Compacting your database

Sometimes it’s necessary to compact your database in order to reclaim disk space (e.g., are you quickly approaching your storage limits?) and/or reduce fragmentation. When you compact your database, you are effectively reducing its file size.

Understanding file size vs. data size

MongoLab’s Shared plans use the fileSize (as opposed to dataSize) value from the output of the dbStats command as the basis for determining whether you are nearing your storage quota. However, when you compare the two metrics, you’ll notice that fileSize is often a much larger value. This is because when MongoDB deletes objects, deletes collections, or moves objects due to a change in size, it leaves “holes” in the data files. MongoDB does try to re-use these holes but they are not freed to the OS.

For a more detailed explanation of how this works, read our discussion about how MongoDB’s size metrics are calculated.

How to compact your database(s)

Sandbox and single-node plans

If you are on a Sandbox or single-node plan and would like to try to reclaim disk space, you can use MongoDB’s repairDatabase command.

If your fileSize is under 496 MB, you can run this repair command directly through our UI by visiting the page for your database, clicking on the “Tools” tab and selecting “repairDatabase” from the drop-down list. Otherwise, you can run the a db.repairDatabase() after connecting to your database using the mongo shell.

We would also be happy to run this command for you - send your request to support@mongolab.com.

The repairDatabase command is a blocking operation. Your database will be unavailable until the repair is complete.

Replica set cluster plans

If you are on a multi-node, highly-available replica set cluster plan and would like to try to reclaim disk space, contact support@mongolab.com and we will help you using the rolling node replacement process described below.

MongoLab’s rolling node replacement process

If you are on a replica set cluster plan with auto-failover, MongoLab’s rolling node replacement process will allow you to maintain high availability and keep your existing connection string during scheduled maintenance. If your application/driver is configured properly for replica set connections, you should experience no downtime during this process except during failover.

What is process used for?

The rolling node replacement process is most commonly used for:

Steps

Overall steps:

  1. Replace each secondary in turn (see the steps under “Steps to replace a secondary”)
  2. Intentionally failover so that your current primary is now secondary
  3. Replace your original primary (now secondary)

Steps to replace a secondary:

  1. Add a new, hidden node to your existing replica set
  2. Wait for the new node to complete its initial sync
  3. Replace your existing node with the new node, updating DNS records

Additional information

Note that at least one intentional failover will be necessary and that it may take 5-30 seconds for a new member to be elected primary. We will email to coordinate with you before we initiate a failover unless you explicitly tell us that this is not necessary.

In addition, MongoDB’s replica set reconfiguration command, replSetReconfig, will be run several times during the above steps. While this command can sever existing connections, these types of disconnects usually have minimal effect on application/drivers that have been configured properly.

Finally, if you are on a Dedicated plan, you may incur additional charges for the extra virtual machines that we run during this process so that you can maintain high availability.