[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Troubleshooting synchronization

Hi Dieter!

Your answers are very helpful, thanks for that!

>>> directory design, I wonder if I am suffering from a misconception here,
>>> i.e. mixing up N-way multi-master and mirror mode possibly.
>> probably

So looking at


What I understand is:

18.3.1. Syncrepl

This is about the syncrepl engine as such. So this is applicable to all
types of replication and it's the technical basics, right?

18.3.2. Delta-syncrepl

I guess this is simple master-slave, isn't it? Though I fail to
understand why this is about deltas while obviously the other mechanisms
aren't, are they?

18.3.3. N-Way Multi-Master

This was the first section which explained something which sounded like
what I am looking for. So I went for it.

18.3.4. MirrorMode

Looking at the config example, I just can't tell the difference to
18.3.3. N-Way Multi-Master except:

- samples in this section are not cn=config based, but I guess that
shouldn't matter but it's just a question of which mechanism I like to
use, isn't it?
- in both N-Way Multi-Master and in Mirror Mode I have serverID,
mirrormode on and syncrepl statements.

So what actually is the difference between Mirror Mode and N-Way
Multi-Master except having 2 servers or three servers?


Dieter Kluenter schrieb:
> Hi Torsten!
> "Torsten Schlabach (Tascel eG)" <tschlabach@tascel.net> writes:
>> Hi Dieter!
>>> The answer is quite simple: do not use multimaster replication in a
>>> production environment. In most cases the requirement for multimaster
>>> replication is just based on poor directory design.
>> If this is a "do not use feature", for what reason has it been included
>> in the software, in the first place.
> Well, there is the protocol RFC 4510 and the OpenLDAP Project is
> aiming to be the reference implementation of this protocol, on the
> other hand is the OpenLDAP Project a community driven project:
> http://www.openldap.org/project
> that is, features not being part of the protocol but may be of
> interest to the community, can be included.
> With regard to multimaster replication, this feature has only been
> included since 2.3 (if I remember correctly) and has undergone heavy
> recoding ever since. I personally consider multimaster replication
> still as beta and not stable for production use.
>>> Slapd in a synchronized environment is, with a few exceptions which
>>> have only been fixed recently, rock stable, I know of environments
>>> with up to 150 consumers.
>> When you say "synchronized", do you mean one master and n slaves?
> Yes
>> When you say, the requirement for N-way multi-master is usually poor
>> directory design, I wonder if I am suffering from a misconception here,
>> i.e. mixing up N-way multi-master and mirror mode possibly.
> probably
>> What we want to achieve is a HA solution where *all* directory data is
>> stored on more than one physical machine. I know I can do that by having
>> a master and a slave. But then I would need to have a mechanism entirely
>> external to slapd that if the master fails I turn the slave into a
>> master and vice versa. (However this could be reliably achieved.)
> What you describe is Mirror Mode.
>> So the idea for N-way multi-master was just: I can point the DNS entry
>> to whatever server in my cluster (possibly there may be more than two)
>> and it will be a writeable directory and I won't ever loose any
>> information I write into that LDAP cloud.
> OK, this requirement does not include multimaster replication, but
> only Mirror Mode of a HA cluster of providers and chaining write
> operations of consumers to the active provider.
> -Dieter