MongoHQ elastic deploys with 1GB = oplog tailing for $18/month

[Tim Heckel]

Disclaimer: I am not affiliated with MongoHQ in any way, just excited about this new service.

MongoHQ just released an elastic deploy option and intend on updating their UI shortly to allow you to enable oplog tailing for a given db user. In the interim, you can create a new db user and ask them to manually promote this user to allow oplog access, and they're happy to do it. This is a huge benefit to Meteor developers, as previously you had to get admin-level access on a dedicated machine, which starts > 100/month, which is usually out of reach for most devs when they're just launching their sites.

MongoHQ even went out of their way to mention Meteor oplog tailing in their announcement:

http://blog.mongohq.com/new-elastic-deployments-now-available/

Hope this helps!

Tim

[Carl Littke]

Just migrated from another db on mongohq to their elastic deployment. Works nicely and the process was very simple. We've been using mongohq for a couple of months for our production app and I must say they do a good job. Their UI is really easy to understand and I even got some help on optimising queries and structuring our data. Thumbs up!

[Almog Koren]

This looks great will be trying it out for my new app thanks for sharing 

[Gadi Cohen]

Tim, thanks for posting this.  It's a pretty big deal, as you describe.  Wish they'd done this a bit earlier, I could have avoided writing our own Mongo deployment software :>  Because yes, as you poiinted out, the admin plans necessary for oplog access were prohibitively expensive.

Looks like MongoHQ just became the #1 option for PaaS based Meteor deploys.  Great work!

They also announced this on the list (after you :)) here:

https://groups.google.com/d/msg/meteor-talk/HXHX_T6xNsI/u0nG-os0LjoJ

On Wednesday, March 19, 2014 6:26:29 PM UTC+2, Tim Heckel wrote:

[Albert Stephan]

What did you guys set for MONGO_OPLOG_URL to get this working?

I have an elastic deployment on MongoHQ, but setting

MONGO_OPLOG_URL=mongodb://oplogger:pass...@candidate.1.mongolayer.com:10380,candidate.2.mongolayer.com:10380/my_db_name

throws an error:

MONGO_OPLOG_URL must be set to the 'local' database of a Mongo replica set

And trying to set it to the local database as pointed in the documentation fails to authenticate.

MONGO_OPLOG_URL=mongodb://oplogger:pass...@candidate.1.mongolayer.com:10380,candidate.2.mongolayer.com:10380/local?authSource=admin

MongoError: auth fails

 
Thanks

Albert

[Carl Littke]

Hi Albert!

Your oplogger user needs oplog access. Create the oplogger user through the mongohq admin. While doing so, click the "oplogAccess" option. Then use the second alternative you posted, replacing password with the password you chose for the oplogger user. Hope that helps.

On Saturday, March 29, 2014 9:34:28 PM UTC+1, Albert Stephan wrote:

What did you guys set for MONGO_OPLOG_URL to get this working?

I have an elastic deployment on MongoHQ, but setting

MONGO_OPLOG_URL=mongodb://oplogger:password@candidate.1.mongolayer.com:10380,candidate.2.mongolayer.com:10380/my_db_name

throws an error:

MONGO_OPLOG_URL must be set to the 'local' database of a Mongo replica set

And trying to set it to the local database as pointed in the documentation fails to authenticate.

MONGO_OPLOG_URL=mongodb://oplogger:password@candidate.1.mongolayer.com:10380,candidate.2.mongolayer.com:10380/local?authSource=admin

[Albert Stephan]

Hi Carl,

Thanks for your reply, but I still can't get it to work. I get a MongoError: auth fails error. 

I've added oplogger user from MongoHQ admin. I see:

Is it normal that I don't see the oplogAccess: true attribute?

I set 

MONGO_OPLOG_URL=mongodb://oplogger:password@candidate.1.mongolayer.com:10380,candidate.2.mongolayer.com:10380/local?authSource=admin

Also, in the case above, if I have multiple databases running on the same cluster, how will my Meteor app know which database to read from? In my example, I would have a dev and production database running on the same elastic cluster on MongoHQ (the collection names are the same). 

Thanks,

Albert

[Albert Stephan]

Ah, got it resolved. The authSource flag has to point to the database name. That makes sense. This works:

MONGO_OPLOG_URL=mongodb://oplogger:password@candidate.1.mongolayer.com:10380,candidate.2.mongolayer.com:10380/local?authSource=my_db_name

Albert

[Shawn Lim]

Cool. Do I still need to set MONGO_URL for my meteor app in this case?

[Arunoda Susiripala]

Yes.

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Arunoda Susiripala]

AFAIK,

There is no bandwidth limitation.

But there are CPU and Memory limitations.

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

On Fri, Jul 25, 2014 at 1:19 PM, Danijel Cole <dan.ba...@gmail.com> wrote:

Looks good. I like the practicality of using a mongoDB service..however i'm concerned about the performance implications of doing so with a production app.

Lets say you wanted to run a lean start-up with your Meteor tier hosted on AWS in a geographic region similar to where you've chosen to host your MongoHQ instance. Would the latency cost be negligible enough to disregard, in exchange for the developer time saved by not having to setup / manage your own mongodb deployment?  

Also, the 'Automatically scale at $18/GB per month' pricing doesn't discuss bandwidth limits. Is bandwidth not charged?

cheers 

[Shawn Lim]

I actually didn't think that it was worth it setting up at mongohq though. It was fairly easy to get my replica sets up in a DigitalOcean box and keep a decent meteor server running. Of course this loses the benefits of separating the server and the databases... but I found that I experience better performance with my app when my mongodbs are placed in the same box as my meteor server because of the local connection. 

By the way, I do not know what to set for the MONGO_URL, they only provide a replica set url which i assumed is for MONGO_OPLOG_URL

[Carl Littke]

We have been using mongohq from day 1 at lookback.io. Separating the db and the app servers have made scaling much easier than it otherwise would have been. Can't say I've noticed any latency because of this (but we haven't performed any real tests since everything is working fine as it is).

[Kyle McLaren]

@Danijel The latency cost will be acceptable if app and DB run in the same geographic region (currently MongoHQ shared plans can run in US-East and EU-West).

On Friday, 25 July 2014 09:49:20 UTC+2, Danijel Cole wrote:

Looks good. I like the practicality of using a mongoDB service..however i'm concerned about the performance implications of doing so with a production app.

Lets say you wanted to run a lean start-up with your Meteor tier hosted on AWS in a geographic region similar to where you've chosen to host your MongoHQ instance. Would the latency cost be negligible enough to disregard, in exchange for the developer time saved by not having to setup / manage your own mongodb deployment?  

Also, the 'Automatically scale at $18/GB per month' pricing doesn't discuss bandwidth limits. Is bandwidth not charged?

cheers 

On Thursday, 20 March 2014 02:26:29 UTC+10, Tim Heckel wrote:

[Kyle McLaren]

@Shawn your MONGO_URL will point to your main MongoDB server (with additional hostnames for Replica Sets) like so (taken from MongoHQ blog): 

mongodb://<user>:<password>@candidate.11.mongolayer.com:10240,candidate.0.mongolayer.com:10240/<dbname>

Your MONGO_OPLOG_URL should point to the local database on your primary. You will need to add a special 'oplogger' user with read-only access:

mongodb://oplogger:<password>@candidate.11.mongolayer.com:10240,candidate.0.mongolayer.com:10240/local?authSource=<dbname>

[Arunoda Susiripala]

Running mongodb on the same server seems pretty okay at start. But when it comes to production, you need to run replicas for redundancy. Then you need to monitor stuff.

There are ways you can do them without MongoHQ or similar. But $18/GB is great. Since they don't charge for bandwidth. Most other cloud databases(AWS, Google Cloud, cloudant) charge for the bandwidth.

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!