invalidation by namespace Re: Listing all keys on a server: why?

Martin Atkins mart at degeneration.co.uk
Fri Jul 28 23:34:36 UTC 2006


Serhat Sakarya wrote:
> On 7/28/06, Martin Atkins <mart at degeneration.co.uk> wrote:
>>
>> It does mean that whichever node the revision counter is on becomes a
>> single point of failure for that namespace, too. If that node goes down
>> you've lost the entire namespace until it comes back up again, at which
>> point you're worse off because your counter goes back to zero.
> 
> 
> Clients would handle failure by remapping the salt key to another node. 
> This
> results in a) having stale keys on different nodes and b) key resets 
> both at
> node failure and at node recovery. Poor keys...
> 

The "best practice" for memcached is not to do remapping on node 
failure, despite that being the plan to start with, because node deaths 
are often brief and so all you really achieve is screwing up the hash so 
that all of the keys need to get recreated, and so you end up storing 
loads of things twice.

Assuming the node is only down for a few minutes (which is most 
frequently the case, unless you have really unreliable servers) you just 
end up with a bit of slowness for a while as the app has to hit the real 
backing store, and then some pain while the cache rebuilds when the node 
comes back up. The rest of the cluster is unaffected.





More information about the memcached mailing list