Re: Documentation volunteer (was: Cluster replication: multiple masters)

[Adam Williams <awilliam@whitemice.org>]

>>My take so far is it works well.  You need each server set up like a
>>master (running a slapd and slurpd), and each configured to replicate to
>>all the others.
>Okay, but my question still remains: why does this require a code
>change (and related build headaches) of any kind whatsoever?  

Because the replication protocol doesn't really support multi-master, it
is a dangerous hack.  (Not that dangerous hacks don't work in some
environs).

>Why not just configure each slave to also be a master?  

You'll get conflicting updates eventually.  And referrals works just
fine,  it has been enough for DNS all these years.

>Why won't slurpd simply puke all changes to all servers?

Because it isn't magic.  It has to know what should be replicated where,
or you'll end up with nasty replication loops.

>short, what does the code do?

>From ftp://kalamazoolinux.org/pub/pdf/ldapv3.pdf -

An experimental option called "multimaster" allows multiple servers to
operate as masters,  both processing updates and updating each other.
To use multimaster -
	#define SLAPD_MULTIMASTER 1 in portable.h
after doing ./configure and before compiling.
This changes how a server handles incoming replications.  A multimaster
server will not write out changes to its replication log if the
connection performing the modification was the configured updatedn, 
thus avoiding an infinite loop.
This option breaks the ability to daisy-chain replication,  but is
stable if this type of replication is configured so that masters do not
get updated by more than one other master.