On starting meteor 1.4.1, I get this message:
Your development database is using mmapv1, the old, pre-MongoDB 3.0 database
engine. You should consider upgrading to Wired Tiger, the new engine. The
easiest way to do so in development is to run meteor reset. If you'd like to
migrate your database, please consult
https://docs.mongodb.org/v3.0/release-notes/3.0-upgrade/
I though Meteor looks after the mongodb side of things under the hood and I would need to fix it if it is not broken, Will it be a problem if left as is or should be better to upgrade, and how to go about it? Thanks
You can check it in here.
https://guide.meteor.com/1.4-migration.html#update-to-mongo-3_2
MDG recommended you to update. minimum version supported by metetor1.4 is Mongodb Version 2.6.
Related
Apologies if this question is too open-ended.
I have inherited an aging tech stack and am required to upgrade our 200GB MongoDB Community Edition v3.4 installation (hosted on Ubuntu 20) to MongoDB v5 in order to support some new features.
MongoDB advises that to install v5.0, one must be already on MongoDB v4.4:
https://www.mongodb.com/docs/manual/release-notes/5.0-upgrade-standalone/
They say that if you are on a version older than 4.4, then you need to incrementally upgrade to v4.4 before upgrading to v5.
However, if you follow the links in that official upgrade tutorial, you will find that in order to upgrade to any version of MongoDB, they insist on you upgrading version-by-version, successively.
So for me on v3.4 the upgrade path will look like this:
v3.4 -> v3.6 -> v4.0 -> v4.2 -> v4.4 -> v5.0.13
Following these tutorials:
https://www.mongodb.com/docs/manual/release-notes/3.6-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/4.0-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/4.2-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/4.4-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/5.0-upgrade-standalone/
I'm not entirely sure why this is necessary, as the tutorials themselves seem to mostly involve copying over newer binaries and then setting a feature compatibility version in the database config.
To test whether this was necessary I did a mongodump of our entire v3.4 database and then installed a standalone MongoDB v5.0.13 on the same server and then mongorestore to the new v5.0.13 database. Everything seems to work fine, mongorestore spent two hours recreating all the indexes as its last step (something various articles told me would not happen using the mongodump/mongorestore method).
I am able to connect Mongo clients to this new v5.0.13 Community instance without issue. All the data is there and I am able to query it just fine.
So my question is, why does MongoDB strongly advise doing the upgrade incrementally, one version at a time when dumping the database and restoring it to a new version of MongoDB seems to work just fine?
The only issues I have currently is having to rewrite some client code which is using an older Mongo Java driver. This is something I am going to have to do regardless of the upgrade method I used.
Our MongoDB instance is Community Edition and is a single, standalone instance (not a replica set) so I don't know if this matters. Perhaps the upgrade process described by MongoDB is for Mongo Cloud or for Enterprise?
I'm just looking for clarification on whether the simpler method I tried is going to cause me issues. Maybe I've missed something I hadn't considered.
Why is 3.0.* ok but 3.2 version has to specifically be 3.2.6? Is 3.2.1 ok?
Any version is fine when doing a fresh install with parse-server but from parse.com you will not be able to move to 3.2. Seems that migration tool wont allow it.
I moved to 3.0 and from there did backup/restore to 3.2.
However i would always strongly suggest that one in general runs the latest version if you can.
I do know that all test on mongodb 3.2.6 are passing including geo queries.
We have an app that uses the C# Mongodb client lib from mongo, version 1.1.0.4184
This code currently runs against mongodb 2.6.4
We would like to stand up a new mongodb server, the current version (3.2.11). Will our code run against newer mongodb?
It really depends what you mean by "will it run". The MongoDB v1.1.0.4184 C# driver was released in June, 2011 and dates to roughly the MongoDB 1.8 server release timeframe. This driver version is certainly no longer tested or supported, and will not be fully compatible with newer server features like the WiredTiger storage engine (default in MongoDB 3.2+) or SCRAM-SHA-1 authentication (default in MongoDB 3.0+).
The MongoDB documentation includes a reference table with recommended version(s) of the drivers for use with a specific version of MongoDB: C#/.NET Driver Compatibility.
If this is a production system I would strongly recommend taking the time to update and test a supported version of the C# driver for use with MongoDB 3.2 (eg. the v1.11 C# driver). I suspect it is very likely you will encounter fixed (or novel) bugs/behaviour using a driver that is more than five years old. Your application won't be able to take advantage of many of the newer server features, and this obsolete driver predates specifications such as standard Server Discovery and Monitoring (SDAM) behaviour.
That said, assuming you aren't using any features the driver isn't aware of your code may continue to run (or at least appear to run) successfully. In my opinion doing so is a high risk deployment strategy.
Yes, i am using it, but however we have to chek on specific features, which you were using. using MongoDB latest driver is much better in terms of latest features and there are few features were removed(like 'eval()').
I have work a lot with MongoDB 2.6, then I decide to start using MongoDB 3.0.2.
1) When I create an Database using the shell command, the command return true but
the database is not created.
use NewDatabaseName
2) When i try to create some collections, sometime is created and sometime no
I'm using Debian 64Bit, latest version.
Anybody is having this issue?
MongoDB 3.0 is not compatible with all GUI.
For example today MongoVUE do not work at all.
But MongoDB Management Studio sounds like the only one that really work.
Also here some other post related.
mongodb version 3.0.0 client robomongo mongovue
Yes your problem is GUI-related. You can check out different tools on this page:
http://mongodb-tools.com/
I will most probably be using MongoChef from now on.
This may be a dumb question, but I am confused about something. I have downloaded mongodb 2.6.4(latest) version to my mac, and deleted old mongodb folder which had executables and other stuff. But whenever I execute 'meteor mongo' command from my meteor.js application, it is opening MongoDB shell version 2.4.9, not the latest one. Why is this happening? Where is this old version is coming from? How can I use the latest version in meteor.js application?
Thank you
Meteor 1.0.x supports both 2.6 and 3.0. It ships with 2.6 locally.
http://info.meteor.com/blog/meteor-104-mongo-cordova-template-subscriptions
Meteor includes its own version of mongodb as a part of its bundle when you ran curl https://install.meteor.com | sh
It does this so its not a hassle to install and they can bundle the correct supported versions with it.
Meteor doesn't yet officially support 2.6.4 on the account of some oplog differences, though you can get it to work without the oplog without any issues, and with the oplog with a couple of issues.