Gavin Henry wrote: > ----- "Ryan Steele" <[email protected]> wrote: > >> Hi folks, >> >> I'm in the process of setting up about six nodes, and tossing around >> the idea of having either 2 masters in MirrorMode >> (traffic to the "active" master is managed externally) with 4 slaves >> (each of whom will refer their writes to the active >> master). I'm automating some of the setup, and in an effort to >> simplify the configuration, was wondering if I might be >> better served by simply having 6 masters with an identical >> configuration, each of which refer their writes to the active >> master (a separate IP/hostname on a virtual interface on one of the >> masters). >> >> So, the question becomes, 'are there any downsides I'm not aware of?' >> It seems to me that the advantage with the 6 >> masters is that, aside from the consolidation of configs for the >> automated setup, I now have 6 write-capable nodes >> instead of 2. And, provided I chain the writes to the active master, >> I shouldn't have to worry about incompatible >> writes/partitioning. Any thoughts, advice, recommendations? Thanks! > > If you have 6 masters you don't need to chain anything as that is Multi > Master. > > I'm confused as to why you are chaining from a master to an active master. > You should have > either two MirrorMode nodes (with management) and chaining slaves or full > Multi Master.
I want to use MirrorMode, but between six nodes instead of two (the example in the Admin Guide uses three, so I figured using more than just two nodes was fine). As such, I need an active master to ensure that two masters don't write to the same entry or entries at (or near) the same time and cause a conflict/partition. I figured that having six masters in MirrorMode, instead of two masters and four slaves, would allow me to cut down on configuration while boosting my redundancy. I would use chaining on all of them to both keep the configs identical (less management overhead) and ensure that I don't run in to the aforementioned conflict scenarios. Is there anything I've failed to consider in deciding that using six masters in MirrorMode is more desirable than having two masters in MirrorMode with four slaves? > The way you've described above isn't very clear and sounds messy. What your > clients/apps need > from the slaves? What is the usage pattern etc. I thought it sounded more simple - six masters with identical configurations (both cn=config and backend database replicated via identical syncprov/syncrepl configurations on each node), with all writes being directed to the active master; the chaining just guarantees that any writes erroneously sent to an inactive master would be forwarded on to the active master. In contrast, with the two masters and four slaves, the two masters must share syncprov/syncrepl configs and replicate cn=config and backend data to and from each other, while replicating the backend to the slaves; the six slaves would in turn need entirely separate syncprov/syncrepl configs since their cn=config wouldn't be in MirrorMode, to ensure that they replicate backend data to nobody and from the active master, and because they'd still need to chain/refer writes to the masters. Does the above logic seem sound or flawed to you? Anything I've glossed over or perhaps misunderstood? Thanks again for all the advice and insight - I truly appreciate it! Respectfully, Ryan
