> -----Original Message----- > From: fedora-directory-users-bounces at redhat.com > [mailto:fedora-directory-users-bounces at redhat.com] On Behalf > Of Sam Tran > Sent: Friday, July 08, 2005 10:59 AM > To: General discussion list for the Fedora Directory server project. > Subject: Re: Advantages of using FDS > vs OpenLDAP? > However according to that paper multi-master replication could lead to > inconsistencies: > http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt > > What do you think? Well, the paper is not wrong - MMR is not an atomic write model (everything in that draft stems from this fact), rather it is a loosley consistent one. However that doesn't mean that MMR is not right for your deployment. You must consider how likely those problems are to turn up in your deployment, how much that will matter, and how easily and quickly you can recover from them - only you can answer that. Balance the issues raised in that draft versus having only one master, which means a single point of write failure without any write load balancing. In many (most?) larger deployments (and even small distributed ones) these advantages far outweigh any issues that arise from lack of MMR lack of atomicity. To address some of those points directly: 4.2 allocation serial numbers True the delete/add value trick to ensure atomicity of serial numbers does fall down. But nobody says you have to keep the entry in the replicated portion of the dit (or in other words, the same entry), with just a little admin overhead it should be simple enough to manually partition the uidNumber space between servers - 4 billion possible values ought to provide enough partition space such that it can be done once and forgotten about. 4.3 Allocation of single-valued authority information A rehash of 4.2 but an example where the work around for 4.2 won't work. I wonder how many real world applications really do this though. 4.4 Entry resurrection Actually I agree with this. It has been something I have argued vigourously against (and failed) in the past. MMR still obeys the order of events of operations (eventually) just like a single server for all operations EXCEPT for delete which it will _reverse_, all other operations if replayed on a single server will result in the entry ending up the same. I called them the undead entries. Though Kurt does not raise the issue, I consider this a security risk too. Imagine a deployment where employees can update certain attributes of their entry. A simple script could keep a fired employee entry from getting deleted (though _I hope_ that deployments use the account inactivation features in such situations - you see my point.)
