MongoDB version 3.0 now GA on MongoLab

We're excited to announce that MongoDB 3.0 is now available on all MongoLab plans. Since the release of version 3.0 was announced in March, we've done extensive testing to ensure that it is production-ready for MongoLab users. For those looking to upgrade or create a new MongoDB 3.0 plan, you can do so through our self-service UI. Version 3.0 offers several valuable improvements, including collection-level locking; a new, more secure user authentication mechanism (SCRAM-SHA-1); and the WiredTiger storage engine. Each of these three improvements is described in detail below.

There are two important items to note, as you consider upgrading to version 3.0:

1) A driver upgrade may be required when upgrading your database to 3.0. You can find a matrix of 3.0 compatible drivers in the MongoDB 3.0 release notes.

2) Our release of support for version 3.0 comes with the default MMAPv1 storage engine. Support for the new WiredTiger storage engine will come later, most likely with the release of MongoDB 3.2, where it is expected to become the default storage engine for MongoDB. For more information about our support for storage engines, please read the section entitled "WiredTiger storage engine" below.

Collection-level locking

The default storage engine in MongoDB 3.0 is MMAPv1, which experienced MongoDB users may recognize as the same storage engine underlying previous versions of MongoDB. Although the name has stayed the same, MongoDB now offers collection-level locking; in prior versions of MongoDB, the database-level lock was the finest-grain lock.

How will this impact you?  In versions of MongoDB prior to 3.0, database-level locking would lock the entire database any time an operation that required the write lock (e.g. insert, update, delete) was issued. With collection-level locking, a write operation on one collection will not block the database from servicing reads and writes on other collections.

The effects of collection-level locks on your database deployment will vary depending on your data model, but generally you should see performance improvements, particularly in write-heavy workloads that target more than one collection.

SCRAM-SHA-1 authentication

In MongoDB 3.0, SCRAM-SHA-1 has now replaced MONGODB-CR as the default authentication mechanism. For the security buffs, MongoDB has written an interesting blog post that speaks to the advantages of SCRAM (short for "Salted Challenge Response Authentication Mechanism"). Two notable benefits include improved security against "malicious servers," and heightened resistance to "replay attacks."

Depending on your driver version, you may need to upgrade your driver to a 3.0- (or SCRAM-) compatible version. If you're unsure if your current driver version supports SCRAM, be sure to check out MongoDB's release notes. Again, make sure you double-check your driver version before you upgrade, or your driver will start throwing errors and you will experience downtime!

WiredTiger storage engine

MongoDB 3.0 ships with two storage engines: the default MMAPv1 engine (with collection-level locking), and the new WiredTiger storage engine (with document-level locking). We're very excited about WiredTiger and have already begun testing internally. We look forward to supporting WiredTiger for MongoLab production plans when it is expected to become the default storage engine in version 3.2.

Questions?

As you will discover, there are numerous changes and enhancements to 3.0. We recommend that you explore the full list of changes and improvements in the MongoDB 3.0 release notes. If you have any questions along the way, drop us a line at support@mongolab.com and we'd be happy to help!  For example, if your MongoLab deployment experiences high write loads, and you would like to discuss how best to leverage collection-level locking to enhance your performance, please drop us a line!

One Response to MongoDB version 3.0 now GA on MongoLab

  1. Nikolay Lastochkin 2016/03/19 at 3:44 am #

    OK, MongodDB 3.2 is here and where is WiredTiger? Or are you worried that the custemers will have to pay you less because of smaller database size?

Leave a Reply