mongodump and mongorestore to upgrade databases

[davidmo]

hello all,

i know there has been a lot written about this. the conclusion seems to be that in order to upgrade a server or replicate cluster that has data

you have to upgrade  from major release to major release until you hit the target. and, from what i can see in the notes, you cant bypass this by doing a

mongodump from the old server version into a new server version (unless it just one version higher). i have 2 problems with this that i was please hoping

for some advice. 1st - what if for the sake of auditing we have a dump that was done from 3.0.x and 2 years from now we have to load it into 3.6.x or a 4.0.x

server because we have upgraded everything ? we have to keep binaries around and resources to be able to spin up servers ?

2nd -  i have a 3.0.x cluster that i want to upgrade to a brand new (hardware) 3.6.x.  i need to test on 3.6 obviously but  when when it is time to cut over i have to go rolling through all the members

my brand new cluster upgrading from 3.0 to 3.6 ?  i just wanted to dump and load from 3.0 to 3.6, not dump and restore to the new hardware and roll through the upgrades. that

seems crazy. has any body done just a dump/restore upgrade ??

thans,

david

[lian....@mongodb.com]

Hi David,

With each major release of MongoDB, there are changes to metadata and configuration within the database due to new features. 

By importing an older version of MongoDB database dump to a newer version of MongoDB, you may run into compatibility issues.

Recommend to review the full list of:

4.0 changes that can affect compatibility with older version of MongoDB

3.6 changes that can affect compatibility with older version of MongoDB

3.4 changes that can affect compatibility with older version of MongoDB

3.2 changes that can affect compatibility with older version of MongoDB

To upgrade your 3.0.x cluster to 3.6, the upgrade requirement is to perform upgrade on all members of the cluster from 3.0 -> 3.2. 

Then repeat the same process to the next major release until the targeted major version is reached. 

With each major upgrade, it is import to also consider the Driver Compatibility.

Before upgrading MongoDB, always test your application in a staging environment before deploying the upgrade to your production environment.

Additional resources:

• Rolling upgrade procedure (Blog)
• Upgrade Replica Sets
• Upgrade Sharded Clusters

Regards,

Lian

​

[Astro]

Hi Lian,

With each major release of MongoDB, there are changes to metadata and configuration within the database due to new features. 

 Does upgrading the mongodb replica set based on the documentation(e.g this doc) takes care of such changes in metadata or configuration itself? Or Some additional actions are required to avoid data compatibility issues during upgrades?

Thanks!

[lian....@mongodb.com]

Hi Astro,

User-visible metadata and config changes are manual upgrade steps for replica sets and sharded clusters. For example, when upgrading from 3.4 to 3.6 the FCV (Feature Compatibility Version) setting is not automatically changed.

This is outlined as step 4 (Enable backwards-incompatible 3.6 features) of Upgrade Process in Upgrade a Replica Set to 3.6 guide.

In addition to David’s post, in-place upgrades minimise downtime and ensure compatibility by stepping through adjacent major release upgrades using tested procedures. It is possible to use mongodump & mongorestore if downtime is acceptable, but skipping one or more major releases with mongorestore may result in errors due to stricter validation in successive releases of MongoDB. For example, stricter index validation in 3.4.

Regards,

Lian

​