Migrating to Meteor 1.4

babrahams · July 27, 2016, 1:49am

mongodump -h localhost -port 3001 -db meteor

… doesn’t seem to work with 1.4 apps (it does work with 1.3.5.1 apps). So as long as you mongodump before updating, I guess there’s still a way to migrate the db.

I do know that doing this still works with 1.4:

mongorestore -h localhost -port 3001 -db meteor

Is the reason that mongodump doesn’t work with 1.4 something to do with using the 3.2 version of Mongo?

tmeasday · July 27, 2016, 2:28am

It works for me with a vanilla 1.4 app – perhaps it doesn’t work with a 1.4 app that is using an old db?

EDIT:

Worked for an updated app too. I’m not sure what you are seeing @babrahams

babrahams · July 27, 2016, 3:03am

I just took an existing Meteor 1.3.5.1 project, dumped the database, did a meteor update followed by a meteor reset. Successfully restarted the app, did mongorestore -h localhost -port 3001 -db meteor and saw the restored data. Everything fine so far and working as expected.

Then I tried (for interest sake – in case on some other app I wanted to update now and switch to Wired Tiger by means of a quick and easy meteor reset later) to mongodump -h localhost -port 3001 -db meteor, which didn’t dump the database. It created a folder called dump, with a nested folder called meteor, but there were no contents to the meteor folder. The mongo version is 3.2.6, node 4.4.7, Meteor 1.4, OSX 10.11.5.

tmeasday · July 27, 2016, 3:26am

Ah, yeah I see the same behavior when dumping from a 3.2 DB.

But the issue is that we were using an old version of mongodump (I’m pretty sure you were too because you wrote -port rather than --port and that worked with mongodump version 2.6 but not version 3.2 for me).

When I use a 3.2 version of mongodump, all is good.

babrahams · July 27, 2016, 3:27am

Haha… you’re absolutely right @tmeasday. Thanks for picking up on that!

With mongo 3.2 installed (instead of 2.6!), the command to dump the local database is:

mongodump --host localhost --port 3001 --db meteor

And dump this can be restored with:

mongorestore --host localhost --port 3001 --db meteor

janat08 · July 29, 2016, 10:45am

not a fan of pre-releasing breaking changes through 1.3.5.x rather than 1.x that would comply with versioning convention. Spend a week pondering as to why my mongo stopped working.

tmeasday · July 29, 2016, 1:33pm

Not sure what you are referring to @janat08?

janat08 · July 29, 2016, 2:56pm

I belief that since your recommend to first upgrade to 1.3.5.1 before to 1.4 to make sure that everything is in order as both versions share same code it is then not backwards compatible breaking the convention where the at least the last numbers of version are just patches. Otherwise I just downgraded and still have issues with mongo.

michaelcole · July 29, 2016, 4:14pm

Also, Compose.io doesn’t support WiredTiger as far as I know. Could running WiredTiger locally but on in production be a problem?

Compose offers 4g wired tiger w/3 nodes for $133 a month. Deployments -> Create Deployment -> MongoDB (not classic) -> Check the box.

My understanding is mmap and WiredTiger are API compatible. Here’s a MongoDB blog post for more info.

tmeasday · July 30, 2016, 4:00am

Everything in order apart from the breaking changes? For instance Mongo + Node were not updated in 1.3.5.1

Generally speaking, “downgrading” isn’t really supported. Why not just revert to an older version of your code?

madc0w · August 1, 2016, 2:31pm

Current Meteor version: 1.3.4.1

“meteor update --release 1.3.5.1” and “meteor update” both result in the same error trace below. Not sure what to do about it…

=> Errors while initializing project:

While loading package fourseven:scss@3.4.3:
error: Command failed:
module.js:340
throw err;
^
Error: Cannot find module '…/'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object.
(/home/mad/.meteor/packages/fourseven_scss/.3.4.3.9ec67g++os.linux.x86_64+web.browser+web.cordova/plugin.compileScssBatch.os.linux.x86_64/npm/node_modules/meteor/compileScssBatch/node_modules/.temp-1i4zv75/node_modules/node-sass/node_modules/cross-spawn/node_modules/spawn-sync/node_modules/try-thread-sleep/node_modules/thread-sleep/node_modules/.bin/node-pre-gyp:15:20)
at Module._compile (module.js:456:26)
at Object.Module._extensions…js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)

npm ERR! Linux 3.19.0-65-generic
npm ERR! argv “node”
"/home/mad/.meteor/packages/meteor-tool/.1.3.5_1.1xxjkfx++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/npm"
“rebuild” “–no-bin-links” "–update-binary"
npm ERR! node v0.10.46
npm ERR! npm v3.10.5
npm ERR! code ELIFECYCLE
npm ERR! thread-sleep@1.0.4 install: node-pre-gyp install --fallback-to-build
npm ERR! Exit status 8
npm ERR!
npm ERR! Failed at the thread-sleep@1.0.4 install script ‘node-pre-gyp install --fallback-to-build’.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the thread-sleep package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs thread-sleep
npm ERR! Or if that isn’t available, you can get their info via:
npm ERR! npm owner ls thread-sleep
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!
/home/mad/.meteor/packages/fourseven_scss/.3.4.3.9ec67g++os.linux.x86_64+web.browser+web.cordova/plugin.compileScssBatch.os.linux.x86_64/npm/node_modules/meteor/compileScssBatch/node_modules/.temp-1i4zv75/npm-debug.log

module.js:340
throw err;
^
Error: Cannot find module '…/'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object.
(/home/mad/.meteor/packages/fourseven_scss/.3.4.3.9ec67g++os.linux.x86_64+web.browser+web.cordova/plugin.compileScssBatch.os.linux.x86_64/npm/node_modules/meteor/compileScssBatch/node_modules/.temp-1i4zv75/node_modules/node-sass/node_modules/cross-spawn/node_modules/spawn-sync/node_modules/try-thread-sleep/node_modules/thread-sleep/node_modules/.bin/node-pre-gyp:15:20)
at Module._compile (module.js:456:26)
at Object.Module._extensions…js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)

npm ERR! Linux 3.19.0-65-generic
npm ERR! argv “node”
"/home/mad/.meteor/packages/meteor-tool/.1.3.5_1.1xxjkfx++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/npm"
“rebuild” “–no-bin-links” "–update-binary"
npm ERR! node v0.10.46
npm ERR! npm v3.10.5
npm ERR! code ELIFECYCLE
npm ERR! thread-sleep@1.0.4 install: node-pre-gyp install --fallback-to-build
npm ERR! Exit status 8
npm ERR!
npm ERR! Failed at the thread-sleep@1.0.4 install script ‘node-pre-gyp install --fallback-to-build’.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the thread-sleep package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs thread-sleep
npm ERR! Or if that isn’t available, you can get their info via:
npm ERR! npm owner ls thread-sleep
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!
/home/mad/.meteor/packages/fourseven_scss/.3.4.3.9ec67g++os.linux.x86_64+web.browser+web.cordova/plugin.compileScssBatch.os.linux.x86_64/npm/node_modules/meteor/compileScssBatch/node_modules/.temp-1i4zv75/npm-debug.log

robfallows · August 1, 2016, 2:40pm

Anecdotal evidence suggests you try

meteor remove fourseven:scss
meteor update
meteor add fourseven:scss

chabekah · August 13, 2016, 2:31pm

@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 · August 23, 2016, 6:18pm

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 · August 23, 2016, 6:57pm

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 · August 23, 2016, 7:01pm

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

janat08 · August 27, 2016, 8:46am

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 · September 1, 2016, 11:12pm

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

juliomac · February 21, 2017, 7:49pm

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:

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?
If I update to WiredTiger/Mongo 3.2 will I have to change hosting plan on Mlab?
What happens to data? Will I have to dump before and restore new db later or will this update “just works”?

sashko · February 21, 2017, 10:10pm

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!