PECL memcache extension
olivier.favre-simon at club-internet.fr
Tue Feb 7 13:34:45 UTC 2006
Then may be you have to give short life, say 1 or 2 minutes, to keys you
don't want to be stale...
Not deterministic at all, but that way stale keys on the A server would
delete themselves if server B is up for at least this expiry time (so
live keys get directed to it again).
BTW thanks for bringing this issue. It's clear now this situation might
also be a problem for my apps with some "sensitive" keys, at least in
theory since my memcached processes/servers are hardly down...
Timo Ewalds wrote:
> Paul G wrote:
>> ----- Original Message ----- From: "Don MacAskill" <don at smugmug.com>
>> To: "memcached mail list" <memcached at lists.danga.com>
>> Cc: <mikl at php.net>
>> Sent: Friday, February 03, 2006 5:37 PM
>> Subject: PECL memcache extension
>> -- snip --
>>> If "set key1" is destined to ServerB's buckets, but ServerB fails, I
>>> don't want "key1" being redirected to ServerA instead. Why?
>>> Because when ServerB comes online, I now have "key1" in two places,
>>> and one of them will now potentially get out of date. Should
>>> ServerB fail again before "key1" has expired, calls to "get key1"
>>> will return old stale data from ServerA instead of fresh data or no
>>> Make sense? Am I doing something wrong? Can the PECL extension
>>> work in this fashion?
>> maybe i'm missing something, but i don't think the case you're trying
>> to protect against is actually going to occur. once serverB comes
>> back online (and gets added to the rotation, which gets rehashed),
>> all further queries for key1 will again be run against it, whether
>> it's set or get. sure, you get a stale entry for it on serverA, but
>> if it never gets queried for it again, who cares?
> You don't care if all goes well, but if serverB fails again, it will
> drop back to serverA again, which still has stale data which it is
> perfectly happy to serve as if it was not stale.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.danga.com/pipermail/memcached/attachments/20060207/48e5c5b1/signature.pgp
More information about the memcached