Yeah, there's a lot that is not yet documented, especially rarely-used features like this. We welcome bugs filed against us for missing documentation, and can help out on our dev list as well.
-=Bill On Tue, Sep 2, 2014 at 10:23 PM, Ankur Chauhan <an...@malloc64.com> wrote: > Hi Bill, > > Thanks for the pointer. I will have a look at aurora again but last time I > had a look the docs were pretty scarce so I pretty much just gave up. Maybe > it deserves some more time on my part and digging through the source. > > * Maybe some of the aurora devs here might want to publish more > tutorial/docs on the nifty features in aurora :-) > > -- Ankur > > > On Tuesday, September 2, 2014, Bill Farner <wfar...@apache.org> wrote: > >> Another alternative is for the scheduler to reliably place your instances >> on the same hosts every time. This comes with its own pitfalls, but isn't >> rolling the dice as much as hoping a whole replica set is not moved. >> Aurora, for example, implements this with a 'dedicated' scheduling >> constraint specified in the job description. >> >> -=Bill >> >> >> On Tue, Sep 2, 2014 at 9:01 PM, Ankur Chauhan <an...@malloc64.com> wrote: >> >>> Hi Vinod, >>> >>> Thanks for your reply, You raise very good points and I realize that >>> mesos is ephemeral. So far I am making the assumption that mesos (based on >>> constraints set) would be responsible of keeping enough replicas alive that >>> data loss does not happen and when a task is killed from a replicaset, it >>> has enough (or atleast one) replica to recover from. The only way to get >>> around this problem completely is to have the MESOS-1554 resolved or use >>> some form of underlying volume that is available to all tasks/slaves where >>> replacement nodes can be started. >>> >>> >>> On Tue, Sep 2, 2014 at 5:35 PM, Vinod Kone <vinodk...@gmail.com> wrote: >>> >>>> I'm not aware of any ports of MongoDB on Mesos, but the one gotcha to >>>> keep in mind when porting database frameworks is that the task/executor >>>> sandbox in Mesos is ephemeral. IOW, when an executor exits the sandbox gets >>>> cleaned up (not immediately but after certain time based on the garbage >>>> collection algorithm). So if a MongoDB executor writes its state/db in the >>>> sandbox then that data is irrecoverable if the task/executor terminates >>>> (e.g., LOST). Having said that, follow >>>> https://issues.apache.org/jira/browse/MESOS-1554 for future work in >>>> this area. >>>> >>>> >>>> On Tue, Sep 2, 2014 at 2:50 PM, Ankur Chauhan <an...@malloc64.com> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I apologise for the repost but wanted to get some responses. I am >>>>> evaluating mesos and wanted to know if anyone has successfully used >>>>> mesos (with or without docker) as a means of managing a mongodb >>>>> deployment. Currently, I have 8 shards where each shard is a 3x >>>>> replicated replicaset and contains > 500GB of data. >>>>> >>>>> >>>>> I was wondering if someone has tried to deploy and maintain a mongodb >>>>> deployment using mesos (or maybe tell me why this is not advisable), any >>>>> gotchas and preferred methodology for deployment. >>>>> >>>>> -- Ankur >>>>> >>>>> >>>> >>> >>
