Re: Multimaster further work

[Derek Simkowiak <dereks@itsite.com>]

> limitation. One solution would be to allocate a range of UIDs to each
> server so that UID allocations can proceed without reference to other
> sites. Some scheme to avoid DN clashes would also be needed - if this
> were done by giving each site its own part of the DIT then we would
> not need multi-master at all...

	This comes up as a suggestion every once in a while (partitioning
the directory layout between servers).  But like Andrew said:

> [...] then we would not need multi-master at all...

	That is not really multi-master.  To me, multi-master is all about
homogeneity; one basic configuration that can be blindly load-balanced,
failed over, whatever -- without concern as to where packets are being
routed or which node of a cluster is currently "the master".


> One problem though: deletions..... We would need to keep deleted
> entries around so that they could have timestamps for the time they
> were deleted!

	If I only had the time... Use Spread (http://www.spread.org/) as a
backend and OpenLDAP would become the safest multi-master LDAP server
around.  It offers several levels of safety, including the ability to make
sure all the other nodes in the cluster have received and confirmed the
data.

	(Upon further reflection, Spread needs a backend of its own --
it's a networking library, not a database -- so Spread should be in a
layer of abstraction above the database 'backend' modules.)

> > (For the archive:  this is another reason why directory service !=
> > general-purpose DBMS.)
>
> Absolutely right.

	I recently tried to set up 2.0.27 with two masters.  I had several
problems (my notes are not in front of me and this is not the best thread
for them anyway), so I'm going with a master-slave setup.  It's been a
real disappointment (and several hours of unfruitful effort).


--Derek