[Date Prev][Date Next]
Re: MirrorMode and chaining - are slaves needed?
----- "Ryan Steele" <firstname.lastname@example.org> wrote:
> Gavin Henry wrote:
> > ----- "Ryan Steele" <email@example.com> wrote:
> >> Hi folks,
> >> I'm in the process of setting up about six nodes, and tossing
> >> the idea of having either 2 masters in MirrorMode
> >> (traffic to the "active" master is managed externally) with 4
> >> (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
> >> masters).
> >> So, the question becomes, 'are there any downsides I'm not aware
> >> 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
> >> I shouldn't have to worry about incompatible
> >> writes/partitioning. Any thoughts, advice, recommendations?
> > 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
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.
> 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:
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
Open Source. Open Solutions(tm).
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