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.

benr.

On 5/16/11 2:32 AM, Marcel van Dorp wrote:

Hi,

I'm investigating the same thing. I found some interesting docs on www.zytrax.com/books/ldap

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.

Regards,

Marcel

...

Thanks,

...

benr.