Migrating to Meteor 1.4

[chabekah]

@babrahams Thanks for these simple commands… really helped me out. However, the restore didn’t quite work for me. After doing the mongodump, and clearing the database with meteor reset, when I started up meteor again and tried to restore, your mongorestore command resulted in a core dump (!) when the restore got conflicts between the newly created mongo database and objects in the restore. I had to add the --drop option to stop this. BTW, I also needed to specify the folder name of where the dump was. The command that worked for me was:

mongorestore --host localhost --port 3001 --drop --db meteor dump/meteor/

Actually, after double-checking, it looks like the version of my dump and restore were 2.6 rather than 3.2. Maybe 3.2 is cleverer…

[wray]

I have one complaint with 1.4 and it’s pictured above. In the guide, there’s a section called “Upgrading to 1.4” which links to this thread. I’ve tried to understand what changes I need to worry about, but ultimately didn’t want to be bothered with digging through the forums for hours on end. Really, 1.4 would feel a lot nicer if this one misleading link in the guide be removed or updated or… something. It doesn’t go anywhere. It doesn’t link to anything. There’s are recommendations below to refer to, but they aren’t in a bulleted list like other sections of the guide. The heading font sizes are so similar that it isn’t easily suggested. What would make me (and perhaps others) feel better would be an ordered list of steps clearly numbered with command line examples—no ambiguity.

[sashko]

The link is just broken, it’s supposed to point to this section: https://guide.meteor.com/1.4-migration.html#recommendations

Edit: fixed the link

[wray]

I’ll admit I over-reacted (pun intended).

[janat08]

Well fine, there aren’t any instructions on moving to 64 bit mongo which is what prevents from some of my collections forming. I’m already on 3.2.6.

[janat08]

Explains how to use separately installed Mongo, given no upgrade path from 32 bit to 64 bit which is installed by default on windows.

MongoDB - Meteor 1.4 32-bit deprecated is an issue?; Using MONGO_URL

If you install it on your local dev machine, it will be `mongodb://localhost:27017" by default. Meteor dev defaults to a database name of meteor by default, but I suggest explicitly specifying the name as in my first reply, so something like mongodb://localhost:27017/database_name. MongoDB has a configuration file, which you can edit if you need to change things like the port number. https://docs.mongodb.com/manual/tutorial/install-mongodb-on-windows/

[juliomac]

Sorry if this question sounds stupid, but I am so used to the simplicity and how updating Meteor apps “just works” that I am a bit freaked out by some of the potential breaking changes this time. I am specially concerned about the MongoDB update that does not seem to be “automatic”.

Currently I have a Meteor application running on Galaxy and accessing Mongo on a Multi-node replica set deployment on Mlab.com (former MongoLab).

My app is currently running in production on Meteor 1.3xx with MongoDB version: 3.0.12 (MMAPv1).

I plan to update it to Meteor version 1.4. However this version recommends using a different driver, WiredTiger, and MongoDB 3.2.

My doubts are:

1. By updating my app on Galaxy, what will happen do my db at Mlab? Will it upgrade itself to WiredTiger / Mongo 3.2? Or will I have to do it manually? Is there a way to prevent it and keep on current version/driver?
2. If I update to WiredTiger/Mongo 3.2 will I have to change hosting plan on Mlab?
3. What happens to data? Will I have to dump before and restore new db later or will this update “just works”?

[sashko]

You don’t need to upgrade your database - feel free to continue using the same version as before if you don’t need any of the MongoDB engine improvements!