----- "Ryan Steele" <[email protected]> wrote: > 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.
Sorry Ryan, but I think you misunderstand MirrorMode. MirrorMode is Active-Active Hot-standby. It's designed for just *two* nodes. The example in the admin guide is for full Multi-Master, but only showing three masters. Anything more that two is Multi-Master. > 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? See above. If you have 6 Multi-Master and replicate cn=config and the rest of the data, you will have your desired outcome. > > 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. They handle this all themselves via SyncRepl when in Multimaster mode. As all writes have to go to all masters. > 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. Correct. > 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! Just the terms MirrorMode and Multi-Master. Check out: http://www.openldap.org/doc/admin24/replication.html#MirrorMode%20replication http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master%20replication Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E [email protected] Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
