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

Serhat Sakarya serhat at sakarya.nl
Fri Jul 28 20:04:04 UTC 2006


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 only solution that springs readily to mind is to treat the revision
> counter like any other cached value and store it in persistent storage as
> well as in memcache.


It's somewhat odd to end up needing capabilities beyond memcached, when the
whole idea was to have an efficient implementation *within* the bounds of
memcached.

You could of course use mysql as persistent fallback storage for the keys,
but that might be a bit too ironic.

It may be better to implement namespaces directly in memcached, but... since
namespace data may be spread over dozens of nodes, won't these nodes have to
communicate or replicate data?

Regards,

Serhat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20060728/296f5371/attachment.html


More information about the memcached mailing list