While not all encompassing, this page should answer some of the basic questions we’re asked about our MongoDB offering. If you feel something should be added please don’t hesitate to send us a ticket!

What is the upgrade process like?

The high level process for a major version upgrade, i.e. 2.4.x to 2.6.x, or 2.6.x to 3.0.x, requires two 30 second interruptions while the binaries are changed to the newer versions. The interruptions are during the mongoS restarts, and then again during a stepdown of the primary mongoD node(s).

At this point the cluster is running the newer version of MongoDB, but we haven’t finalized the upgrade process just yet. The final point of no return is when $authSchemaUpgrade is run. This changes the authentication method internally in Mongo and cannot be reverted. It requires a complete dump and restore to a new instance running an older version to roll back to a previous major version.

Due to the finality of the authSchemaUpgrade, we always have the cluster run for at least a 48 hour period to ensure there are no issues with the new version and your application. Once that period has ended without issue we run the command to complete the upgrade. We’d also caution against creating new databases, sharding collections and adding new users during this period if possible.

Replica Set differences

The major difference is there are less interruptions for a Replica Set upgrade, as there are no config servers nor mongoS to upgrade. This means there is only one 30 second interruption while a new primary is chosen. All other aspects remain the same.

What is a compaction and why is it important?

A compaction is simply a way to keep MongoDB’s space usage in check. High level it rebuilds the data files to ensure it’s only using as much space as it needs. We explain in more detail in our What is a Compaction? guide.

Can I get my data back if I accidentally delete my instance?

In most cases yes! We keep deleted instances for a few days after deletion, but we cannot guarantee the time period due to our internal cleanup process. If you need to restore a deleted instance please create a ticket so we can investigate the availability.

Why are there different types of replica sets?

Historically, our traditional replica sets have consisted of 2 members and 1 arbiter. However, moving forward, our traditional and Parse optimized replica sets will both include 3 members. This will provide a more robust and resilient architecture for your replica set. his extra member will come with no additional costs or increas to your monthly bill. If you’re on one of our traditional 2 member replica sets don’t worry! We’re working on a plan to get an additional member added to your replica set.