memcached replication

[Brenton Alker]

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