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: [EMAIL PROTECTED] ------------------------------------------
