Re: Multimaster Replication

[Travis Groth <lists@netfoo.org>]

Thanks guys, I did find what i need.

As far as the *why* of multimaster...well, lets say you run small sites,
that are separated by vpn tunnels and several hundred miles.  Your
Master goes unreachable, and suddenly your entire ldap structure is
frozen until you can bring the link back up.  Same thing if your Master
dies (though thats the least of your problems at that point).  This
allows for any small segment of the network to die without affecting
everything else.

Since I know everyone is up in arms about multimaster being evil,
unstable, useless, etc, there is another way that I have yet to see
openldap implement.  ADS and NDS use writable slave servers, which then
talk back to the master (at earliest convenience) to resync, with a very
easy way to promote a machine if things get too hairy.  Openldap, as far
as I know, doesn't provide this function.  Its that kind of failover
that you need in an enterprise environment:  Let clients dump their new
data to the local ldap server, and let IT deal with how it gets from
there to the rest of the infrastructure.  Things like DNS entries
updated from dhcp leases are very time critical if you run kerberos, and
multimaster or writable-slave is really the only way to ensure
reliablitity if your network spans more than a single LAN segment.

--Travis Groth

Adam Tauno Williams wrote:
> > I was curious as to the current state of multimaster replication. 
>
>
> See archives, this question gets asked allot.
>
> Always the same answer - experimental, really.
>
>
> > I can 
> > find refrences as to how to do it until 2.1.23...then it seems that if 
> > you have an updatedn you must also have an updateref.  Is there an easy 
> > way to disable this enforcement?  I would like to use multimaster 
> > replication to improve reliability in the event of network failure...I 
> > have a few entries that need to be updated in a rather time critical 
> > fashion.
>
>
> Personally I don't see what multimaster buys you that failover &
> syncrepl can't provide,  except more complexity.
>
>
> !DSPAM:41f7a7f2251543577721244!