Marcus Bointon wrote: > On 5 Sep 2007, at 06:22, Dustin Sallings wrote: > >> Doesn't this mean that you will sometimes write a value to a >> cache, and then later read a value back and get something other than >> the latest value you wrote? Getting known stale values seems worse >> than not getting something from the cache. > > I was thinking that. It might be better to deny the existence of the key > until replication is complete, or make the write synchronous from the > client's point of view.
I don't think you could know to deny the existence of the key if the replication is asyncronous. Unless you are talking about a case where a large key/value has started being copied, but not completed. But I think this wouldn't be the common case. > ... > > Interestingly, though it doesn't get much press, MySQL replication > suffers the same problem - there is no transactional integrity between > replicated nodes - if you write to a master, then immediately read from > a slave, you may not get back what you just wrote. The fix there is not > to do it and use a unified front end like sequoia instead. I wouldn't say it doesn't get much press, it's a known limitation with the asyncronous replication (replication lag), and there are ways around it (cluster is the "best" option for mysql) I think the problem Dustin was describing though, was writing to the "secondary" cache, then that value being overwritten by the primary being replicated with older information. Which can only really be overcome (I think, if anyone knows better tell me :P) by only writing to the master. This means the application, or a proxy for it, must be aware of the master/slave situation. But your right this doesn't solve the lag problem > > Marcus Also, the original poster (Masaaki ?) mentioned it was not "not scalability, or high performance" but redundancy and fail-over. Which means it would only be used in extreme cases, and you could probably forgive the cache misses (dependant on application of course) -- Brenton Alker
