Upgrade mongodb 2.0.7 to latest version

Ops and Admin Installation & Upgrades
,
5

Hi @Fabio_Perez,

It’s normal that you got this error. mongodump latest version (currently packaged with the other Mongo Tools in v100.5.3) isn’t compatible with MongoDB 2.0.X.

It supports MongoDB 4.0 => 5.0. So the good news is, when you reach 4.0, you should be able to mongodump your 4.0 server and mongorestore in a 5.0 final cluster directly.

Since relatively recently (couple of years top but I would say one year) the tools aren’t shipped anymore directly with the mongod binaries. They now follow independent release cycles.

2.0.X is so old that I never touched that version. I wouldn’t touch it with a stick! :smiley: When I see the “master” and “slave” terms, I think it’s because “Replica Set” wasn’t yet a concept at the time and the replication was still really primitive. So yes, I think they are “mirrored” with the old school system.

What I would do if I was in your shoes:

  • Do NOT touch the prod or try to upgrade it.
  • Stop write operations on the prod env.
  • On a new machine, download the MongoDB 2.0.7 binaries. In there you will have mongodump, mongorestore and mongod.
  • Use mongodump 2.0.7 against the 2.0.7 “cluster” and backup the data.
  • Download 2.2.X binaries.
  • Start a mongod 2.2.X single node / standalone
  • use mongorestore 2.2.X to import the data in this new 2.2.X version.
  • Download 2.4.X binaries.
  • Repeat…

I would check the Production Notes / Upgrade instructions for each versions to check if there aren’t additional checks or command to run for specific versions. But it should be more or less OK. Long and annoying but at least this should work…

If you want to speed up the process, you could technically just replace the binaries and keep the same data folder when you start the new mongod version. If you choose this alternative, you definitely need to read the upgrade instructions because you’ll have to run a few additional commands. For example db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } ) is a command that you will need for each version. But you will also have extra “problems” with this approach. For example in v 2.6 => 3.0, you have to upgrade from MMAPv1 => WiredTiger.

So I think in your case, I would dump/restore until 3.0. Then starting from 3.0 it’s faster to just restart the node with the new binaries of the next major release (like 3.0.X => 3.2.X where X is as high as possible) and apply the required extra commands to finish the migration. And repeat until you reach 4.0.
Then you could just use the final latest version of mongodump 100.5.3 and do a final dump => restore in 5.0.9.

It’s a bit complicated when you have to upgrade 11 years of innovations… :sweat_smile:

Am I making sense or I just confused you even more at this point? The cool thing is that if you fail, you can always start over from scratch and don’t destroy the current prod.

Cheers,
Maxime.