We’ve just turned on the ability to upgrade your MongoDB databases to version 3.4 which is also the new default version when you provision a database. For those still stuck on the 3.2.x branch, we’ve also released a new image for MongoDB 3.2.16. As usual, upgrading is an easy one-click process.
As a preamble, let’s have a look at how to upgrade your database on Scalingo. As usual, the upgrading process on Scalingo is as simple as clicking a button on the database dashboard. The following picture shows the message you will see on your database dashboard if you are running the latest 3.2 version (i.e. MongoDB 3.2.16 at the time of writing):
This upgrade can take some time for the biggest databases. During the process, your database will be taken offline. If you wait for the replica set to be released in a couple of weeks, you will be able to upgrade your database without downtime.
Version 3.4.7 has been released. As usual, you can find the corresponding Docker images on our docker hub repository.
You are strongly advised to test that your code still works with the new database version. To ease this task, you can pull the MongoDB version you need from our public docker hub repository and test it locally, with your code, on your workstation before updating. You can also get the same container that we have built for your app and which is running on our infrastructure using our Docker Image Addon.
What is new in MongoDB 3.4
MongoDB 3.4 has been released one year after its predecessor, the 3.2 release. This one year of work allowed the MongoDB team to provide you with some great new features. We will cover in this section some of the most important changes.
For a comprehensive view on the novelty of this release, you can refer to the release note on the official MongoDB website.
MongoDB 3.4 Passes the Jepsen Tests
In early February 2017, a tremendously exciting news spread all over the world, the crowd went down the street to celebrate and cheers the MongoDB team: MongoDB 3.4 passes the Jepsen tests!
Well… It might not be how it happened and you may have never heard of these Jepsen tests but this news is really important.
The Jepsen initiative aims at improving the safety of distributed system (databases, queues, consensus systems, etc). In this objective, they give conference talks, public analysis and training classes. But what we are concerned with in this article is the Jepsen test suit: a bunch of stress tests that put a distributed system under pressure with extreme failure and random race condition such as unsynchronized clock and repeated failure. Some consider passing the Jepsen tests as a gold standard in evaluating correctness of data consistency and safety in distributed systems.
More information in this MongoDB blog post.
On a more technical side, MongoDB 3.4 adds a significant improvement in the way strings are sorted. For non-English languages rules to compare two strings are sometimes a bit complicated. MongoDB implemented the comparison rules for more than 100 different languages and locales. You can configure it on your own databases by adding a collation to your indexes.
Native Graph Processing
The flexibility of MongoDB databases scheme let you build some really complex data structure. Some of you may have represented a graph or a tree type hierarchies. Such structure often uncover indirect or transitive relationships. For example, we can represent the Alphabet Inc. company structure as a tree. Alphabet Inc. owns many company such as Nest, Calico, DeepMind and Google Inc. Google Inc. itself owns Ads, Cloud, YouTube or Android. Indirectly, Alphabet owns Android.
To query such information, MongoDB introduces the new
pipeline. Developers can specify a maximum depth and apply filters to only
search graph nodes that meet specific query predicates.
More information on the official documentation.
A Few Compatibility Changes
As with any new version, MongoDB deprecates a few features, and drops the support of some old deprecated features. You can find a comprehensive list in the official documentation. You may want to go through this document to ensure that your code will still run with MongoDB 3.4.
After an upgrade from MongoDB 3.2 to 3.4, some new
are only accessible if the
featureCompatibilityVersion parameter is updated
3.4. Note that during the upgrade process of a Scalingo database, we
do update this parameter.