mupx support for external MongoDB Replica Set

[occasl]

I definitely have the need to expose my MongoDB to other services as part of my solution but I notice in the docs that this is currently not supported. Is there an ETA for this? I have my own MongoDB replica set so can I call to that in the meantime?

[MasterJames]

This is relevant... https://github.com/arunoda/meteor-up/issues/57

I believe it's more of a meteor issue. I suppose Galaxy is your hands free solution (still in Preview). I'm thinking when AWS EFS also floats out of Preview, things will change or at least a solution (here or elsewhere) will materialize. It may take some time/releases still to sort this problem out. I figure 1 year is a safe guess on both Preview delays, and a couple of cycles to stabilize the mongo replica-set and meteor oplog system. I dream of a day multi-server writes is fully functional through a shared filesystem via oplog tailing/syncing on EFS etc. [I'm I dreaming or not?]

I think if your big enough and in Need sooner then both of those Previews are currently available/negotiable, or the expertise to get your system there will be available financially.

[occasl]

I'm not sure I understand what you mean by "it's more of a meteor issue." With my current production deploying, I'm using my own MongoDB with replica sets and I reference that through the MONGO_URL environment variable. That works great!

Similarly, could I just set the MONGO_URL as an environment variable in my mup.json to point to my existing MongoDB instance that I set up on another EC2 instance? This way I could still use mupx for my AWS Meteor deployment and just leverage my own MongoDB installation.

[roeeyud]

I'm having the same issue. It seems that changing MONGO_URL in mup.json doesn't change the MONGO_URL environment variable when the server runs. When I print out the MONGO_URL I see mongodb://mongodb:27017/

[derwaldgeist]

I'm a bit irritated by this issue. Where in the docs can I find the info that external replica sets are not supported? I just connected my mupx-based EC2 instance to a Compose.io replica set, and everything seems to work fine. Did I miss something?

[MasterJames]

From the link above last line it sums it up really with. "For others there are many ways to setup replicas" I think (what you missed) it's possibly particular to mup/mupx and managing multiple deployment machines or similar. Currently beyond it's capability or even as it's explained in the link #57 "its purpose". A new version is forming at kadirahq current. I hope all your wishes have been heard and interpreted into what is surly a complex task. In another thread just earlier there was this link to this meteor plugin for redis. https://atmospherejs.com/slava/redis-livedata so ya pick your poison. This might be really nice on AWS EFS (Shared Filesystem op_log). Can't wait to try when it's out of Preview.

To add clarity to my words before. I explored the notion that with just oplog on a shared filesystem you don't need a master slave configuration. I have yet to try. When it's possible by the majority to launch on 5 machines via EFS it will become more possible that that (?-able) configuration becomes more & more desirable. IMHO. Please discuss.

[derwaldgeist]

Thanks for answering. Yet I have to admit I still don't get this issue and your explanation. I've seen #57, but in this issue Arunoda already refers to MongoHQ:

I assume MongoHQ deal works for many.

So I interpreted #57 in a sense that replica sets are not supported to be installed by mupx, but are supported if you have set-up MongoDB yourself (or use a service like Compose.io) and point your mupx installed server to this replica set using Mongo URLs.

And at least for me, it seemed to work as expected. This is why I was asking myself why this issue is titled "mupx support for external MongoDB Replica Set"?