First, I don’t see how you are going to make this works. There is such a gap between 3.2 and 4.4 that there are probably a few differences in the 3.2 dump you will get and the 4.4 dump that you need to be able to restore on a 4.4 cluster.
I do have a solution though but it does require to migrate to Atlas… which also has the advantage to guarantee that you will never have to do that ever again.
The MongoDB Atlas Live Import supports a migration path from 3.2 to 4.0 and later so definitely 3.2 to 4.4 or even 5.0. This has the benefit to secure the migration.
Once you are in 4.4 or 5.0 in Atlas, nothing prevents you from taking the snapshot back home and restore on your home-made cluster. Or stay in Atlas if you prefer to stay there and avoid other troubles in the future with some other DIY or upgrade job.
Atlas provides all this kind of automation & monitoring so you don’t have to worry about it and focus on the real added value of your product.
Just for information, here command mongodump (V3.2) to create a dump from a MongoDB 3.2 instance and restore with mongorestore (V4.4) works without error to MongoDB 4.4 instance.
Related to MongoDB Atlas, I am on an on-premise environment and I can not reach/use external cloud services. How I can deal for the best with these constraints?
Well it’s not something that MongoDB tests. Maybe it does work, maybe not perfectly. Maybe some complex field types might not survive the transfert.
Without Atlas the official solution would be to migrate 3.2 => 3.4 => 3.6 => 4.0 => 4.2 => 4.4 => 5.0 but as you can guess, it’s a bit long to do and each major release has it’s bundle of things that needs to be done between each migration. Like setFeatureCompatibilityVersion() for example.
With this solution, it would be possible to achieve a zero down time upgrade. If you can afford a downtime, then your solution is probably better but test it in and out to make sure there is no data loss.
All the steps are important. They are here for a reason.
When you have your RS running with the new binaries and you are done following all the upgrade instructions. Also, make sure your RS is stable (rs.status()) before anything else.
No because during the rolling upgrade procedure, you need to check that the new node has rejoined successfully the RS and you need to make sure that it’s catching up with the primary and rejoining as a Secondary. You can only upgrade the next secondary node once the previous one is done upgrade and the RS is back in a stable state.