RE: Multimaster further work

["Clayton Donley" <clayton.donley@octetstring.com>]

Hi Derek,

> 	The whole idea behind the MAX_LAG_TIME number is that, once that
amount of time has passed, we are guaranteed to know 
> that there are no more conflicting writes coming in for a particular
DN.  In practice I expect it to be something like the
> ping time (which is a round trip, btw) times two or three, to account
for network spikes.

Actually, the issue here is that it doesn't actually guarantee anything,
since a master could go down between the time a change is committed to
the time it can be replicated (among many other scenarios). Not to
mention that there are all sorts of conditions where replication may get
backlogged to an extent. MAX_LAG_TIME seems to add additional complexity
while not really helping the servers server figure out the actual order
of changes, etc...

If you were looking to come up with a workable solution, it would seem
to me you would still need time synchronization to aid in determining
change sequence, as well as a process for handling exceptional
conditions/conflicts (perhaps as simple as notifying an administrator of
unresolvable conflicts as is done in some loosely synchronized systems).

Also, I read your original post and the MD5-related checking could be
avoided by using change sequence numbers or such that indicate the
version of the data in the entry.

As for the need for multi-master. Certainly it's a nice tool to have in
the arsenal, but I've worked with many clients that have gotten along
fine without it in some very large scale environments.

Just my thoughts (not being an OpenLDAP server developer or anything,
but having dealt with many of these hard issues myself from time to
time).

Clayton

--
Clayton Donley,
OctetString
clayton.donley@octetstring.com