Replace mongodb binaries all at once?

Amanullah_Ashraf · 2020-10-28T06:36:21.737Z

While upgrading mongodb from 3.2 to 4.4 replica set. Do I need to download and replace the binaries of all the version from 3.2 to 4.4 all at once and then restart the mongod at the end or I have to restart the mongod after every version download and restart the server, and then download 3.4 and replace and restart, repeat the process till end?

chris · 2020-10-28T12:06:36.555Z

Hello again @Amanullah_Ashraf

Yes they have to be started, version by version. More pertinent, you have to follow all the steps in each version’s release notes for the type of upgrade(standalone, replicaset, sharded cluster).

Some of the versions introduce change in storage engine, others changes to authentication and yet others changes to default bindings.

This is thoroughly documented.

Stennie_X · 2020-11-02T04:31:27.635Z

Hi @Amanullah_Ashraf,

The recommended (and most throughly tested & documented) approach is an in-place upgrade which minimises downtime and gives you opportunity to test for compatibility issues before upgrading to the next major release.

In-place upgrades require upgrading via successive major releases (so from 3.2 => 3.4, 3.4 => 3.6, etc). All members of a replica set or sharded cluster must be completely upgraded to the same version before continuing to the next major version upgrade.

There are a few ways you can fast track a migration through multiple major version upgrades.

Preparation

As @chris noted in one of your other discussion topics, you should upgrade your clients/drivers for compatibility with your target server version. I would test and implement driver upgrades before commencing any server upgrades. Given the age of your original deployment, newer drivers may have API compatibility changes requiring an update to your application code. Drivers are generally backward compatible with a great range of MongoDB server versions, but older drivers will be missing support for newer APIs and authentication mechanisms.

Be sure to review the relevant Release Notes and Compatibility Changes information in the MongoDB manual, and follow any version-specific Upgrade procedures. There have been a lot of changes since MongoDB 3.2 was released in 2015!

Regardless of the upgrade approach you take, be sure to take backups of your deployment so you have a straightforward recovery path in the unlikely event that something goes dramatically amiss.

Upgrade with Automation

This is the safest upgrade path:

Use Cloud Manager Automation (currently supports MongoDB 3.4+) to migrate your on-premise deployment to a supported version of MongoDB. There’s a 30-day free trial of Cloud Manager automation which will probably cover your migration period.
Use MongoDB Atlas Live Migration (currently supports MongoDB 2.6+) to upgrade to a modern version of MongoDB hosted in the cloud. You can either restore a backup from your Atlas deployment on-premise, or consider using Atlas as a more convenient management solution going forward.

Upgrade with Backups & Downtime

If downtime is acceptable and you have a large number of major releases to upgrade through, you can also consider a migration using mongodump and mongorestore.

This approach will require more testing and patience because you are still subject to major version compatibility changes and will encounter different issues depending on the provenance of your data. This approach will also not support upgrading user & auth schema, which is supported via the usual in-place upgrade path.

Unlike an in-place upgrade, dump & restore will recreate all data files and indexes so you may run into some (fixable) errors. The most likely complaints will be due to stricter validation of index and collection options which would not cause an issue for an in-place upgrade. I definitely recommend testing this procedure in a staging/QA environment with a copy of your production data to ensure there are no unexpected issues that might otherwise delay your production upgrade.

Regards,
Stennie

system · 2020-11-13T11:45:33.013Z

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.