[Date Prev][Date Next]
Re: MirrorMode vs MultiMaster Questions
Looking even more at the code and the commit history, it turns out that
in 2006 when MirrorMode was added it was in fact called "multimaster"...
the name was simply changed to mirrormode later with no major changes to
the code. So, it really looks like MirrorMode is MultiMaster, the only
difference being a 2 node multimaster shadows only its peer, whereas a
3+ node multimaster shadows multiple.
This is perhaps best seen in the modify code, where if the configuration
is not SINGLE_SHADOW (ie: MultiMaster) it passes a referral instead of
accepting the operation.
Therefore, the language in the docs is more specific than I realized.
"Active/Active MirrorMode" and "N-Way MultiMaster" are accurate and if
you omit them you miss the point.
The real point here is that in MirrorMode you're told to only send
writes to a single node. I want a 2-Way Multimaster in which I can send
writes to either. And it in practice you can, but you're not (according
to the docs) supposed to. Its like the authors didn't trust their own
synchronization code. I can only infer that there might be problems in
high write environments to 2 nodes... from which I further infer that
for environments using LDAP for NIS-Replacement where writes are very
rare its not a practical problem. In this type of setup I just want
basic HA, I don't want load balancers and multiple shadows, just 2
slapds in A/A config.
On 5/16/11 2:32 AM, Marcel van Dorp wrote:
> I'm investigating the same thing. I found some interesting docs on
> On 05/16/2011 10:24 AM, Ben Rockwood wrote:
> > I'm having some problems understanding the subtleties of MirrorMode vs
> > MultiMaster configurations. Any help with the following questions would
> > be helpful:
> > 1) It looks like the only real difference between a MirrorMode and
> > Multimaster configuration is whether or not the RIDs are different. In
> > MirrorMode both sides have the same rid, in Multimaster they are
> > different. Is that so?
> - From what I understand, with mirrormode=FALSE the consumers are
> readonly, and updates are referred back to the provider.
> with mirrormode=TRUE, the consumers are mirrors of the provider, and
> updates can be processed locally. The multimaster config (using
> syncrepl) then updates all other masters.
> > 2) Passing through the code, "MirrorMode" is really "Single Master" and
> > MultiMaster is just "not Single Master". But the code path to determine
> > whether it is single master or not confuses me. How does slapd actually
> > determine this?
> During startup, the deamon is provided with the URI to listen on. I'm on
> Debian, where this is configured in /etc/default/slapd. Doing a 'ps ax
> |grep slapd' shows this:
> 7741 ? Ssl 0:00 /usr/sbin/slapd -h ldap://127.0.0.1:389/
> ldap://hostname.domain.com/ ldaps://hostname.domain.com/ ldapi:/// -g
> openldap -u openldap -F /etc/ldap/slapd.d/
> The serverID also refers to this URI, to determine the local process
> (after all, serverIDs will also be syncrepl'd):
> olcServerID: 11 ldaps://hostname.domain.com/
> olcServerID: 12 ldaps://another.domain.com/
> olcServerID: 13 ldaps://thirdhost.domain.com/
> > 3) For MultiMaster, the docs show using syncrepl to replicate cn=config
> > and the directory (or directories if you have more than one)
> > independently. Is it really necessary to replicate cn=config if the
> > configuration isn't changing? (What I'm really looking for here is to
> > find out if there is state information in cn=config thats being used or
> > if its simply a good idea to ensure the configs are the same by using
> > syncrepl.)
> The main issue for me, is that I need to have the ACLs in sync, and
> those are in cn=config. I'm still working on this, so please bear with
> me if above info is not completely correct.
> > Thanks,
> > benr.