Re: MirrorMode and chaining - are slaves needed?

[Ryan Steele <ryans@aweber.com>]

Gavin Henry wrote:
> ----- "Ryan Steele" <ryans@aweber.com> 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