[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Re[4]: openldap-server-2.2.29: multimaster support
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.
Ing. Pierangelo Masarati
Responsabile Open Solution
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati@sys-net.it
------------------------------------------