Upgrade mongodb 2.0.7 to latest version

Ops and Admin Installation & Upgrades
,
8

Hi @Fabio_Perez,

I joined MongoDB when 2.0 was the current release, so I have some familiarity although we’re digging into ancient history now ;-).

A few questions about your environment & goals:

  • Is 48Gb the size of your data files or the size of the data?

  • Is downtime during upgrades acceptable?

  • Is your cluster hosted in the cloud (or does it have great connectivity)?

  • Do you have a representative staging/QA environment where you can test upgrade processes?

  • Have you already looked at updating your MongoDB driver versions? There have been significant changes in wire protocol and API since MongoDB 2.0, so a driver upgrade will likely be a prerequisite to your server upgrades.

Some thoughts:

  • Given the size of your data set I would be inclined to perform in-place upgrades (take backups before and after each major version upgrade!) rather than doing a mongodump & mongorestore as those will require downtime and dumping all data through mongod in order to recreate the data files. In-place upgrades are relatively straightforward and quick – the most time consuming aspect is normally validation.

  • Before upgrading I would change from the deprecated Master/Slave topology to the modern Replica Set topology which will allow you to do rolling upgrades to newer server versions.

  • Follow the instructions in the documentation for doing in-place upgrades, for example Upgrading to MongoDB 2.2. Make sure you check the instructions for each major release as there will be some different steps given the wide range of versions you are upgrading through.

  • If you are looking for older server binaries you may find m helpful: GitHub - aheckmann/m: mongodb version management. You should be able to use this to download generic Linux binaries. m downloads and unpacks the binary tarballs and I expect these will be easier to work with than older server packages which will no longer have verifiable signatures (due to expiry).

  • Related reading: Replace mongodb binaries all at once? - #3 by Stennie. If you can get your deployment to a new enough version where automation can be used, you can potentially reduce the number of upgrade steps to get to a non-EOL server version.

If downtime is acceptable and you want to try the mongodump/mongorestore path (not fully tested or supported):

  • Use 2.2.7 version of mongodump to backup your deployment. The 2.2 version of mongodump captures index definitions in *.metadata.json files.

  • Try using latest version of mongorestore to restore this backup into a 5.0 deployment. You may encounter some errors due to stricter validation of collection options and indexes, but they should be fixable (you may have to edit the metadata.json file).

Regards,
Stennie

2 Likes