Open occasl opened 9 years ago
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.
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.
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/
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?
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.
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"?
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?