Migrating to Meteor 1.4

[tmeasday]

The migration guide doesn’t make it very clear how to update your local dev database if you don’t want to just meteor reset it. What’s the best way to do it?

As you would migrate any database, connecting to localhost:3001/meteor, while meteor is running. I’ll try to make this clearer.

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

I’m not sure there are any differences in behaviour, but I guess there could be. In general, I’d probably worry more about making sure my staging environment mirrored production as closely as possible and testing properly there. There are enough differences between development and production that small differences in db behavior tend to not show through.

[sacha]

I get the part about connecting to localhost:3001/meteor, but what do you do next?

[babrahams]

I get the part about connecting to localhost:3001/meteor, but what do you do next?

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]

doesn’t seem to work with 1.4 apps

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]

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]

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]

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]

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]

Not sure what you are referring to @janat08?

[janat08]

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]

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]

@janat08

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.

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]

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]

Anecdotal evidence suggests you try

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

[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/