Hello,
I’m running MongoDB shell version: 2.0.7 and I would like to make a backup of my database and upgrade my server to the latest version. so, I was wondering:
Thanks
Hi @Fabio_Perez and welcome in the MongoDB Community 
!
Some questions for you:
mongod (the cluster) and mongo (the mongo shell) both in 2.0.7?In theory, the “normal” way to upgrade would be to follow the upgrade instructions from each major release and upgrade your cluster from major releases to major releases… But this would mean for you: 2.0.7 => 2.2.X => 2.4.X => 2.6.X => 3.0.X => 3.2.X => 3.4.X => 3.6.X => 4.0.X => 4.2.X => 4.4.X => 5.0.X (with X being the biggest minor version number as possible each time).
You can find the doc for each major releases but here is an example doc for RS 4.0: https://www.mongodb.com/docs/manual/release-notes/4.0-upgrade-replica-set/
Depending on the amount of data, MAYBE using mongoexport / mongoimport could be a solution as it’s JSON instead of BSON but it depends what’s in your data as well. You might have problems with data types, etc. If you only have basic values (string, bool, int, …) then maybe it could be a solution. But that’s a lot of IFs and no guarantee without testing & checking.
Maxime.
Hi Maxime,
Thanks for all that information.
mongodump --host IP_server --db ping --out /home/mongos/mongo2x-`date +"%m-%d-%y"` --gzipFailed: can't create session: could not connect to server: server at 208.85.216.45:27017 reports wire version 0, but this version of the Go driver requires at least 2 (MongoDB 2.6)Here are my answers to your questions:
mongod. Here is what I see when I try to check if the service is running.Checking status of database: mongodb running.
/etc/mongodb.conf filemaster = true
sourse = server2_hostname
Then I went to the config file of that other server and it has this:
slave = true
source = server1_hostname
Tho the replSet value is commented out so it does not have a name.
Does this mean that the replicaSet is active and the DBs are mirrored?
If the data is mirrored between the 2 servers, what would be the process to update ? should try to update the mongodb version on the second server (slave) to at least 2.6 to use mongodump ?
Thanks for your help with this.
Hello,
Just as an update. I’m running mongod on the same version:
mongod --version
db version v2.0.7, pdfile version 4.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! 
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:
mongod 2.2.X single node / standalonemongorestore 2.2.X to import the data in this new 2.2.X version.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… 
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.
Hi Maxime,
Thanks for all that information. You didn’t confuse me a lot LOL but it does seems like a lot of work to catch up with 11 years of innovations hehehehe.
I was wondering how to download the binaries. I wen to this link: Release notes for 2.x
and at one point there, it says “Download the binaries from this link” but that link redirects to someplace else. So I’m not sure as to where I can find all the binaries I need.
Since the data on the backup is changing all the time because it’s live production data. Once I made the first backup on the new server, and run all the updates until almost the latest mongo version, that would mean that the data from that backup won’t be the same as the one currently in production. assuming It take me just 1 day doing all version updates.
If what I’m saying makes sense and it’s true. doing this won’t help me at all because I can update the server while is life so I would lose data while doing the update. right? so maybe is not worth the time doing it? and just leave the server as is until the end of time?
Thanks again for the support
I went here to try to find the archives:
It leads to this link:
https://www.mongodb.com/download-center/community/releases/archive
But…
So you can go to the source where I assume there is truly evrything!
I hope you find what you need 
!
Also, another solution could be to one shot it complete with mongoexport & mongoimport. If you export everything in JSON and these files are correct without complex types, there is no reason why it wouldn’t work. It’s gonna take a long time but… Maybe it’s worth it rather than doing the entire upgrade path. I would give it a shot maybe? mongoexport 2.0.7 a small collection and see if you can mongoimport 100.5.3 in 5.0.9 ?
Cheers,
Maxime.
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
