MongoDB FAQ

This FAQ answers some basic questions about the ObjectRocket MongoDB offering. If you have questions that this FAQ does not answer, submit a ticket.

What’s the upgrade process like?

A major version upgrade (3.4.x to 3.6.x, or 3.6.x to 4.0.x) requires two 30 second interruptions while the upgrade changes the binaries to the newer versions. The interruptions occur during the mongos restart and the stepdown of a primary replica member.

After the binaries change, the cluster begins running the newer version of MongoDB, but the upgrade process isn’t complete. The final step is to run setFeatureCompatibilityVersion <https://docs.mongodb.com/manual/reference/command/setFeatureCompatibilityVersion/> and restart the mongos servers for sharded clusters. This step enables new server features for the major version.

Warning

Reverting from this stage requires the removal of any incompatible features with the downgrade version.

Due to the added complexity of setFeatureCompatibilityVersion, we always run the cluster for at least 48 hours to ensure there are no issues between the new version and your application. If there are no issues during the 48-hour period, we run the command to complete the upgrade and restart the mongos servers for sharded clusters.

What is the difference between the sharded cluster upgrade process and a replica set upgrade?

The major difference is there are fewer interruptions for a replica set upgrade because there are no configuration servers or mongos to upgrade. This difference means there is only one 30 second interruption while the upgrade chooses a new primary. Everything else is the same.

What is a compaction and why is it important?

A compaction is a way to limit MongoDB’s space usage. It rebuilds the data files to ensure they are only using as much space as necessary. For more details, see the 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. However, because of our internal cleanup process, we can’t guarantee how long these instances are available. If you need to restore a deleted instance, create a ticket.

Why are there different types of replica sets?

Historically, our traditional replica sets consisted of two members and one arbiter. However, all future traditional and parse-optimized replica sets will include three members. This setup provides a more robust and resilient architecture for your replica set. There are no additional costs for this extra member. We are working on a plan to add extra members to the traditional two-member replica sets of our current customers.