How to upgrade from v3.6.3 to v4.4.5?

I am currently running v3.6.3 on one machine. I have another machine on v4.4.5. I want to move the data from the v3.6.3 machine to the v4.4.5 machine.

I am using ubuntu 18.04

Is this how I should do it:

Make a backup (mongoexport)
Upgrade to mongodb 4.0
Upgrade to mongodb 4.2
Upgrade to mongodb 4.4
Make a backup (mongoexport)
Import the backup data into v4.4.5 machine (mongoimport)

Is all of this needed or can I just mongoexport the data from the v3.6 machine then mongoimport it into the v4.4 machine?

Hi @mental_N_A,

You have multiple solutions to upgrade from MDB 3.6 to 4.4. But before you try anything BACKUP EVERYTHING and of course make sure that you can recreate a 3.6.3 node from your backup so you can always come back and try something else.

  1. The dump solution

mongodump & mongorestore can backup and restore entire databases in a MongoDB cluster. The BSON file they create might not be compatible if the gap between your MongoDB versions is too large (like 2.4 to 4.4 for example). But because 3.6 is not excessively old, it might work just fine.

The big bonus here is that you don’t have to care about recreating your indexes because they will be saved as well in the metadata & they will be rebuilt on the new cluster. And you also don’t need to update 3.6 => 4.0 => 4.2 => 4.4. You can just mongodump in 3.6 and restore in a brand new 4.4 cluster.

It’s not 100% guaranteed that it works as you might find compatibility issues but I would give it a shot.

  1. mongoimport / mongoexport.

This solution is similar to mongodump / mongorestore but instead of using binary files (BSON), you are using plain text JSON files. It’s a lot slower than mongodump / mongorestore & you are not saving the metadata so you will have to recreate the indexes manually.

  1. Upgrading the mongod binaries.

Usually this is the path sysadmins take to avoid down times as it is possible to upgrade your MongoDB Replica Set with a rolling upgrade. This is guaranteed to work this time (unlike the 2 previous methods) but it will require to upgrade from one major version to the next.
In your case, you would have to follow these instructions in this order:

These pages include step by step instructions and contain valuable warnings to avoid surprises like:

Make sure to read these instructions ahead before planning your upgrades and making sure you don’t have anything specific in your MongoDB deployment that would prevent these steps.

EDIT: Adding some links & details about mongodump

Cheers,
Maxime.

I want to go with the first solution (the dump solution). But when I check the docs for mongodump, it shows only 4.0+ versions to be supported. Should I still go ahead and use the dump solution when upgrading from 3.6?

Note: My mongodump version is 100.5.2

There is probably a reason why the docs says it’s not compatible. If you can afford to be offline, then in your situation I would:

  • Take one of the node and stop it.
  • Take a copy of the data folder (/db/data by default) and move it to another server.
  • Upgrade it to 4.0 following the 4.0 upgrade doc.
  • Restart the node in 4.0 standalone.
  • mongodump the 4.0 node.
  • create the new 5.0 or 6.0 (soon!) 3 nodes cluster.
  • mongorestore in this new cluster.

I think this would be safe. And in case something goes wrong, you still have your 3.6 nodes completely untouched and safe.

Cheers,
Maxime.

Yes. I can afford to be offline. And my setup is simple, I have one db server only on the same machine as application. I didn’t setup cluster explicitly so probably I have one node only.
Taking cues from your suggestions, is this what you’d suggest?

  1. Install mongodb-community@4.0 and replace the mongo and MongoDB binary path to this new version
  2. Keep the data folder same as earlier(/db/data) for 3.6
  3. Mongodump
  4. Install mongodb 4.4
  5. Mongorestore the dump from 3rd step

Is that alright?

Note: I want to upgrade to 4.4 only because I see that 5.0 is in active development, and I won’t have time to upgrade this again for at least next 6-12 months.

All the versions that didn’t reach the End Of Life dates are in active development. At the moment it’s 4.0, 4.2, 4.4 and 5.0+. All these versions received minor updates, security patches and backports from the current version.

5.0 is currently the recommended version for prod environments. Many bugs got fixed since 4.4 so it’s better to be there without these known issues in the way. But I understand the logic. :slight_smile:

If you are only using a single node, I would recommend to use a single node Replica Set which would unlock a few interesting features of MongoDB like Change Streams or multi-doc ACID transactions. These features rely on the presence of the oplog system collection that only exists in Replica Sets.

My recommendation for your upgrade would be to leave the current node untouched. Just shutdown mongod and take a copy of the data folder to another PC.

Then you can upgrade to 4.0 and take a mongodump using the latest version. And restore on 4.4 or 5.0 if you feel like it. :slight_smile:

Cheers,
Maxime.

Running into issue while upgrading to 4.0 on Ubuntu 18.04. I am following the guide. On install, I get error - arm64 is not supported.
But the guide mentions to add source repo with arch=arm64. What am I missing? How do I fix it?

There is already an issue on this forum mentioning the exact issue I am facing but without an answer

One more follow up question. Is there a difference between mongodump+mongorestore vs “copy the data folder” approach? Will that create a problem if I take that data folder to 4.0 and then keep upgrading from 4.0 → 4.2 → 4.4 and so on without doing the dump+restore.

If your machine isn’t arm64 then don’t add packages for arm64 architectures.

“Copy the data folder” is faster than a dump. But you can’t migrate from 4.0.X to 5.0.X with that method. You must migrate from one major version to the next.

If you dump/restore, then you can skip major releases in theory but I would recommend to avoid giant gaps and confirm that your mongodump / mongorestore are compatible with the versions you are targeting.

Got it. The path I chose was to upgrade standalone major version step by step 3.2 -> 3.4 -> 3.6 -> 4.0 -> 4.2 -> 4.4, and I am doing it on the same machine. Upgrade to 5.0 and changing the installation to use replica sets, I will cover later after ensuring that this standalone upgrade works without any issues.
So what I understand from your suggestions for this path that - I don’t need to use mongodump/restore as long as I make sure that during the upgrades, the db folder remains the same. Which is always the case because I’m defining db path in mongodb.conf which remains same throughout all the upgrades.

I’m sorry for bothering you so much by asking probably obvious questions, I don’t want to make any mistake.

Do a full backup before you start. Even better, backup the prod, restore it on another server and test your upgrade on that server.

Make sure you read all the upgrade documentation for each version because they contain specificities and special commands that needs to be executed to complete the upgrade.

For example, this one is common:

db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )

But there are other useful information in these docs.

From what I’m reading, always make sure to upgrade to the latest minor version for each of the major one: for example, prefer 4.2.20 to 4.2.1, etc.

Cheers,
Maxime.

1 Like

I accidentally upgraded 4.0 to 5.0(instead of 4.2).

How it happened? I went to link “upgrade standalone to 4.2” and copied the command for keys and source repo but it was set to 5.0 (as it turns out, I have to choose the version no. in the left sidebar). And then as usual I ran sudo apt-get update && sudo apt-get upgrade.

What can I do now?

  • I tried to remove 5.0 source repo and then add 4.2 source repo and key and then run sudo apt-get update && sudo apt-get upgrade. It seemed to work and install 4.2 but when I checked mongod --version, it showed 5.0.9.
  • I tried to uninstall complete mongodb without removing data folder using sudo apt-get purge mongoldb-org. But I get this error
    E: Couldn't find package by regex/glob mongoldb-org-5.0.list 
    E: Couldn't find package by regex/glob mongoldb-org-4.0.list 
    E: Couldn't find package by regex/glob mongoldb-org-3.6.list 
    E: Couldn't find package by regex/glob mongoldb-org-3.2.list 
    

I’m on Ubuntu 18.04 currently

I have to say that it’s a tad easier on MongoDB Atlas. :smiley: It takes like 4 clicks…

I have no idea how you can fix this to be honest. Start over? Does the cluster works in 5.0 ? I don’t manage or install MongoDB with packages (only tar balls) and I’m on Debian. I only manage my prod envs on Atlas so I’m kinda useless at this point I’m afraid.

Thanks for all the help. For now, I uninstalled all the mongo related packages one by one. And then installed 4.4 from scratch. So it is done now, upgraded to 4.4.
Everything seems to work as usual, no issues. But will report back if I face any issues.

2 Likes