----- "Ryan Steele" ryans@aweber.com wrote:
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.
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%20replicatio... http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master%20...
Thanks.
Gavin Henry wrote:
----- "Ryan Steele" ryans@aweber.com wrote:
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.
Hm, but the N-Way MultiMaster documentation has MirrorMode directives... perhaps that's the source of my confusion. Does each master in an N-Way MultiMaster setup, in likeness with the documentation, have an olcMirrorMode directive?
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.
Well, my desired outcome is to have a multi-master setup that guarantees the consistency of single-master setup, so I'm fine with any configuration that adheres to those paradigms.
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.
Correct, but if I allow the initial writes to be made on more than one node, I could end up with a situation where two or more masters perform writes on the same entry or dependent entries, which could result in failed writes and/or partitioning of the data between nodes. So, I'll still need my external traffic shaper to direct the initial writes to only one node to ensure consistency, but as you mentioned I do not need to refer the writes to the active master (which could be done with carefully crafted ACLs, but would add unnecessary complication).
That being said, do I simply need to keep the MirrorMode directives and external traffic shaper, and eliminate any chaining/referrals to achieve my desired setup?
Thanks!
-Ryan
openldap-software@openldap.org