Compose.io and mlab has been famous for MongoDB hosting amongst meteorites.
I see MongoDB coming up with Atlas. Has anyone given it a try?
The wired Tiger database with MongoDB 3.2 is cheaper than compose. Compose gives wired tiger 4GB storage / 1GB RAM for $133, however, atlas provides Wired Tiger Database with 10GB storage and 2GB RAM for $57.
What is the community’s thoughts around this?
I would be interested in this question as well. Did anyone has some experience with MongoDb Atlas?
Cheers
MongoDB Atlas looks like a great service, I’v been playing around with the admin interface and I find that it has way more advanced features than Compose. I’m looking to switch over our DBs since it is also more reasonably priced. Also MongoDB Atlas has point in time backup recovery which for us is a large advantage over the 24 rolling backups of Compose. Also it sets up DB clusters out of the box. Really effortless to get going.
However. I’m now trying to connect with Meteor and struggle a bit. Does anyone know if Meteor supports SCRAM-SHA-1 authentication?
https://docs.atlas.mongodb.com/setup-cluster-security/#create-a-new-mongodb-user-for-the-cluster
Also the database URI is given in this format:
mongodb://[username:password@]host1[:port1][,host2[:port2],…[,hostN[:portN]]][/[database][?options]]
Will this work with Meteor?
When I simply throughs this URI in my MONGO_URL it for some reason ignores the URL and links to my local mongo.
However I’m still playing around with the user settings on Atlas so I might have some mistakes there.
Anyone made some progress on this?
Not used Atlas yet (looking at it), but we have an in-house cluster using V5 authentication (SCRAM-SHA1) and we use exactly that format of MONGO_URL to connect with Meteor.
Thats good to hear. I want to switch over our DBs from Compose to Atlas, which should be simple since we are only at the start of production.
Running the app on local, I call:
MONGO_URL=mongodb://[username]:[password]@cluster0-shard-00-00-xgnuk.mongodb.net:27017,cluster0-shard-00-01-xgnuk.mongodb.net:27017,cluster0-shard-00-02-xgnuk.mongodb.net:27017/[database]?ssl=true&replicaSet=Cluster0-shard-0&authSource=admin meteor --settings set-dev.json --port 3000 run
However for some reason this connects to local DB… Not sure why.
So we’re using
MONGO_URL=mongodb://username:password@host1,host2/database?replicaSet=rs1&ssl=true&readPreference=primaryPreferred&authSource=admin
MONGO_OPLOG_URL=mongodb://username:password@host1,host2/local?replicaSet=rs1&ssl=true&readPreference=primaryPreferred&authSource=admin
But I’ve just spotted the dreaded “shard” word in your url. Are you using a sharded cluster?
No, I definitely have shard disabled on Atlas. But where it gives me the URL in the connection settings. I’ve never used sharing before. Should I remove the shard-00 form the connection string?
It only appears as part of the host name, so it likely has no significance and is just a naming convention. Of course, I could be wrong - we’re not using Atlas here. If you have sharding disabled then you should just use the url you’ve been given.
No - the host name is the host name - use it as given.
That was also my thoughts.
When deploying on localhost it does not give any errors with the URL but only connects to the local DB with no warnings…
I deployed the app with the URL to a stagging server on Galaxy and got the following error:
2016-09-22 13:12:59+02:00MongoError: authentication fail
5bnc
2016-09-22 13:12:59+02:00 at Object.Future.wait (/app/bundle/programs/server/node_modules/fibers/future.js:449:15)
5bnc
2016-09-22 13:12:59+02:00 at new MongoConnection (packages/mongo/mongo_driver.js:216:27)
5bnc
2016-09-22 13:12:59+02:00 at new MongoInternals.RemoteCollectionDriver (packages/mongo/remote_collection_driver.js:4:16)
5bnc
2016-09-22 13:12:59+02:00 at Object.<anonymous> (packages/mongo/remote_collection_driver.js:38:10)
5bnc
2016-09-22 13:12:59+02:00 at Object.defaultRemoteCollectionDriver (packages/underscore/underscore.js:750:1)
5bnc
2016-09-22 13:12:59+02:00 at new Mongo.Collection (packages/mongo/collection.js:103:40)
5bnc
2016-09-22 13:12:59+02:00 at AccountsServer.AccountsCommon (packages/accounts-base/accounts_common.js:23:18)
5bnc
2016-09-22 13:12:59+02:00 at new AccountsServer (packages/accounts-base/accounts_server.js:18:5)
5bnc
2016-09-22 13:12:59+02:00 at meteorInstall.node_modules.meteor.accounts-base.server_main.js (packages/accounts-base/server_main.js:9:12)
5bnc
2016-09-22 13:12:59+02:00 at fileEvaluate (packages/modules-runtime/.npm/package/node_modules/install/install.js:153:1)
5bnc
2016-09-22 13:12:59+02:00 - - - - -
5bnc
2016-09-22 13:12:59+02:00 at Function.MongoError.create (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/error.js:31:11)
5bnc
2016-09-22 13:12:59+02:00 at /app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/topologies/replset.js:1147:54
5bnc
2016-09-22 13:12:59+02:00 at /app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/connection/pool.js:701:7
5bnc
2016-09-22 13:12:59+02:00 at /app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/connection/pool.js:677:20
5bnc
2016-09-22 13:12:59+02:00 at finish (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/auth/scram.js:162:16)
5bnc
2016-09-22 13:12:59+02:00 at handleEnd (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/auth/scram.js:172:7)
5bnc
2016-09-22 13:12:59+02:00 at /app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/auth/scram.js:273:11
5bnc
2016-09-22 13:12:59+02:00 at /app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/connection/pool.js:436:18
5bnc
2016-09-22 13:12:59+02:00 at nextTickCallbackWith0Args (node.js:420:9)
5bnc
2016-09-22 13:12:59+02:00 at process._tickCallback (node.js:349:13)
Which probably means there is something wrong with the way I’m configuring the users on Atlas.
From the Atlas logs I can see that its an SSL mismatch:
2016-09-22T11:32:35.982+0000 I ACCESS [conn16270] SCRAM-SHA-1 authentication failed for [user] on admin from client [IP] ; AuthenticationFailed: SCRAM-SHA-1 authentication failed, storedKey mismatch
2016-09-22T11:32:34.986+0000 W NETWORK [conn16270] no SSL certificate provided by peer
2016-09-22T11:32:34.979+0000 I NETWORK [initandlisten] connection accepted from [IP:PORT] #16270 (22 connections now open)
Any ideas on this? I can connect to the Atlas DB with MongoChef and this URI string.
What version of Meteor are you using?
We are running Meteor V 1.4.1.1
I solved the problem. Now successfully connected with Atlas!
The problem was that I created a user for the app in Atlas which had admin access over the app DB. However, when I substituted the URL with that of the atlasAdmin user, Galaxy could successfully connect to the DB specified in the connection URI.
However specifying the same URL for a local run as I for the stagging deployment for some reason only connects to the local DB. Which sucks since I would like to run my development DB in the same cluster setup as my production DB.
Can you run a local instance which connect to your cluster?
There is a problem with the & symbols in the mongodb URL, try quoting it like this:
MONGO_URL='mongodb://[username]:[password]@cluster0-shard-00-00-xgnuk.mongodb.net:27017,cluster0-shard-00-01-xgnuk.mongodb.net:27017,cluster0-shard-00-02-xgnuk.mongodb.net:27017/[database]?ssl=true&replicaSet=Cluster0-shard-0&authSource=admin' meteor --settings set-dev.json --port 3000 run
For anybody finding this thread, this helped us set up meteor with atlas:
I would chose Atlas over Compose simply because they enable Write Concerns.
Since Compose doesn’t have that, and they host your database on shared resources, you do not have a high guarantee that your writes will succeed.
We’ve been running Atlas now for a few months. So far I’ve been very happy with the service. I get all the same benefits of Compose - fully hosted and managed deployment, auto backups, support, etc - with the added benefits of being a cheaper option and, one of the bigger selling points for me personally, more customization options when it comes to scaling up your deployment.
The switch over to Atlas has been a big win in my book so far!