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