Short story is that I am a Windows developer with no real web development experience and I’ve been handed an off-shored project created in Meteor 1.5.1 and told it needs to be updated to Mongo 4.0 by the end of the month since support for the older versions of Mongo is meant to be canned soon. Obviously this is a big learning curve.
Has anyone done this? I think I’ve been able to upgrade the project to 1.6 - any further than that and I get various build errors.
Any tips on getting an older version of Meteor up to 1.8, or is there any easier way to upgrade just the Mongo to 4.0? And what is involved with that?
99% of the application will probably work with a mongo 4 cluster with no code changes and without updating meteor at all. I’ve got several apps that work just fine connected to mongo 4 even though their meteor versions don’t technically work with mongo 4. Mongo is very backwards compatible as is meteor, the problem is usually with the packages.
Thanks for the reply. So I guess the path of least resistance might be to simply keeping it at 1.5.1 (or maybe 126.96.36.199 if I can safely upgrade to that) and upgrade just the mongo packages and trying to get it to connect to Mongo Atlas? Does it just require a mongo package upgrade?
Hi @arkanis50, Welcome to the forums!
If you are migrating live data, you will need to update the database one major version step at a time.
Going from Meteor 1.5.1, you’re probably better off exporting all the data with
mongodump and importing it into a new Mongo 4 database with
There shouldn’t be many serious issues updating Meteor. I’d suggest looking through the migration guides for each version and see if that helps: https://github.com/meteor/meteor/blob/master/History.md
Build problems sounds like you need to update
@babel/runtime, and maybe other babel related packages in your
Otherwise folks here can help suggest solutions to errors thrown. There’s usually a set of common problems which we’ve encountered before
This is generally true, but the distance is a little too far in this case:
Looking at the pacakge source for Meteor 1.5.1, you can see it uses
firstname.lastname@example.org from npm.
Cross referencing with the mongo driver compatibility table shows that the latest version of MongoDB supported by that driver is version 3.2
Meteor 1.8 is the first version to use
mongodb >= 3.1 and support MongoDB 4.0
Thanks for the replies. I’m wondering if we need to even be on MongoDB 4.0. What is the minimum version of MondoDB that supports Mongo Atlas? I understand we’ve been given a deadline to move over to Atlas… maybe we can get away 3.6?
Yeah, looks like 3.6 is supported by Atlas. I just logged on and it’s in the advanced options when setting up a cluster
Looking at the History, it seems Meteor jumped from Mongo 3.2 to 4.0, and never bundled the
npm-mongo 3.1 driver
Thanks for the replies. So far I have only been working with this project locally and have now upgraded it to Meteor 1.8.
When I now run the project locally I get the following two errors:
(STDERR) MongoNetworkError: failed to connect to server [127.0.0.1:3001] on first connect [MongoNetworkError: connect ECONNREFUSED 127.0.0.1:3001]
MongoError: not master and slaveOk=false
I assume this is because it is no longer using the old Mongo? How do I go about fixing this up to use the newer version of Mongo Atlas, or can this not be tested locally without it connecting to the cloud?
If it’s just local with no data, you can use
meteor reset to re-create the local database and clear any cached files
Haha, that simple. Thank you.
Okay, so I guess I need a rough plan of attack for the production environment when we get to it.
Any thoughts on this:
- Backup the existing Mongo data
- Upgrade Meteor 1.5.1 to 1.8
- Setup the new Mongo Atlas creds/info
- Update our production environment to use new creds (MONGO_URL etc?)
- Restore the Mongo data into Atlas
Appreciate all the help so far.
I would start by backup/restoring the data into Atlas and testing it locally.
MONGO_URL environment variable is set when you start Meteor, it will use that mongo instance instead of starting a local development one. Then you can test with a copy of live data on Meteor 1.8 (or 1.9!) before a deploy
Then when you’re confident, re-deploy with new environment
Thank you - I’ll see how we go over the next couple of weeks. Appreciate the help.
Thank you for asking the question here, I am also going through the same upgrade process for a project.
I would like to ask if there is a continued support for the use of process.env variables in a meteor project of Meteor.settings is favored. I could not get process.env variable to work, as they are seen as undefined.
Any advice on this?