I originally posted this question on ServerFault, but it didn't get any traction, so I thought that stack might be a better forum for this question. My apologies if this out of line.
We are currently running parse-server (v2.7.2) on Heroku (node.js 7.10.1), connected to an mLab mongodb database. I recently received a notification
from mLab that they have been acquired by MongoDB and will be eventually migrating all customers to MongoDB Atlas.
The migration instructions from mLab to Atlas seem fairly self explanatory. My question concerns parse-server itself:
Does our version of parse-server (2.7.2) and node.js (7.10.1) have drivers that will support Atlas MongoDB?
MongoDB feature compatibility will depend on the underlying driver version which you can find by running npm list mongodb in the directory where you installed parse-server.
You can also check the mongodb driver version requested in parse-server's package.json, but a newer driver version may be installed depending on the semver notation used.
It looks like parse-server 2.7.2 uses the mongodb 3.0.1 driver, which is fully compatible with MongoDB 3.4 and 3.6 features according to the MongoDB Driver Compatibility documentation.
The MongoDB Node 3.0.x driver won't support newer features of MongoDB 4.0 (for example, transactions), but you should otherwise be fine with an Atlas deployment using MongoDB 3.4 or newer.
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.
I am currently with Parse-server 2.8.4 and mongo driver 3.1.0 to support a mongoDB 4.0 cluster hosted on MongoDB Atlas.
It was announced that my cluster would be automatically upgraded to mongoDB 4.2 by Atlas.
I am wondering if the Parse-server 2.8.4 supports mongoDB 4.2? If not, which version of Parse-server and mongo driver should I use?
I am hesitant to upgrade to Parse-server 3.0 as my web app is in production and it is said upgrading from Parse 2 to 3 requires a significant amount of change.
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 Meteor 1.2.2 installed and, according to MeteorBlog, it should comes Mongodb v3.0 or higher installed.
However, if a go on Mongo shell (meteor mongo) and do:
$ db.version()
I get: 2.6.7
Shouldn't it be 3.0? I tried meteor update and it says all packages are up to date.
Is there a way to update Mongodb to the latest version as accepted by Meteor?
Meteor 1.1 came with MongoDB support up to version 3 and you're supposed to be able to use Meteor in production along a MongoDB 3.0 database without major problems.
However they decided to keep the 2.6 branch regarding the Mongo version shipped with the Meteor tool and wait until Mongo 3.0 is mature enough before including it along official Meteor releases.
It means that Meteor updates its internal tool MongoDB version automatically, but at their own pace.
The local Mongo environment shipped with the Meteor development tool is something different than the actual Mongo deployment you usually use in production, and it is not required that the 2 versions be the same.
We are using mongo client tools such as Robomongo and MongoVUE from our windows/mac machines. On the mongodb server side, we decided to try out the new MongoDB 3.0.0rc8 with wiredtiger storage. However, we find that we are not able to list any collections from our client tools and mongo shell. If we login to the server box running mongodb, and then start a mongo shell, then we are able to view the collections.
Is this a known problem - that the existing tools like Robomongo and MongoVUE which have been supporting up to 2.6.X are not yet supporting mongodb 3.0.0?
Is there any mongo client that supports version 3.0.0?
Thanks and Regards,
Archanaa Panda
We encountered the same issue today and started evaluating MongoChef http://3t.io/mongochef which looks promising, both seen to UI, features and support for WiredTiger.
Here is the answer to this question i got on google forums from Will Berkeley-
Yes, those tools need to be updated to support 3.0 on WiredTiger. Many
tools enumerate namespaces by querying system collections that do not
exist when MongoDB is running WiredTiger. The mongo shell function
db.getCollectionNames() and the show command pre-3.0 does this, too -
the reason you can list collections on the 3.0 mongod box is that you
have the 3.0 mongo shell installed there.
-Will
I use NoSQL Manager for MongoDB with Mongo 3.0/WiredTiger
This is fixed as of February 1, 2016 with Robomongo.
Using the right version that is robomongo-0.9.0-rc8 fixed my problem.