Re: Re[4]: openldap-server-2.2.29: multimaster support

[matthew sporleder <msporleder@gmail.com>]

On 11/21/05, Pierangelo Masarati <ando@sys-net.it> wrote:
> On Mon, 2005-11-21 at 17:38 +0100, Raphaël Ouazana-Sustowski wrote:
> > On Lun 21 novembre 2005 17:28, John Madden wrote:
> > >> Some of your customers may have been tricked into believing they need
> > >> LB.  If you mean LB on writes, that IS PURE NONSENSE.  The number of
> > >> writes on each of the servers (either masters or slaves) will ever be
> > >> the same no matter how many write entry points you provide (unless you
> > >> believe replication writes are inexpensive; they are not).  If you mean
> > >> LB on reads, I don't see how so-called multimaster could help you there
> > >> more than a single master with an appropriate number of slaves can.
> > >
> > > And furthermore, load-balancing clients across slaves isn't technically
> > > correct --
> > > two clients can still pull different versions of the same object at the
> > > same time
> > > if they hit two different slaves (that's what multi-master is "supposed"
> > > to fix).
> >
> > It is exactly the problem that some of my customers have.  Some poorly
> > written clients try to read an entry just after writting it and don't find
> > it because it has still not been replicated.  Multi-master here is not
> > only a performance problem.
>
> Technically, this could be solved by extending the functionality of the
> "chain" overlay so that, when configured to chain writes to the producer
> when a referral to it is returned by the consumer, it directly writes to
> the consumer after the producer returned success; at the same time (in
> case of slurpd) the producer should not send the change to the consumer.
> However, this is dangerous because there might be other intermediate
> changes to that very same data that didn't make it to the consumer yet.
> Those changes would then apply in an incorrect order.
>
> Maybe we could use something like this:
> - the chain overlay attaches a control to the chained write that
> contains the entryUUID and the entryCSN
> - the producer processes the write; upon success, if the entryUUID and
> the entryCSN were the same, it returns a control response value that
> indicates the consumer can directly apply the write.
>
> This would yield two advantages:
> 1) reduce by 1 the number of sync propagations in the typical case of no
> conflicts
> 2) make the change immediately available on the server that received the
> request
>
> (dam'd: I should have patented this ;)
>
> p.

If a link failure occurs on one node, the write wouldn't be guaranteed
to exist on all servers, which breaks the Atomicity and Durability
requirement of ACID.  (I think the first step in a multi-master setup
should be ACID compliance, by the way).
I believe a journal and a staging database should be employed to first
record the write, and then test its application.  If those are both
successful on all nodes, then a signal can be given to merge that
information into the production database at an agreed upon time.