Evaluating Memcached for our site. Looking for advice.

[J A]

>
> The wiki explains the issue pretty well:
>
>
> http://www.socialtext.net/memcached/index.cgi?faq#how_does_memcached_handle_failover
>
> "With default clients *adding or removing* servers will invalidate all of
> your cache! Since the list of servers to hash against has changed, most of
> your keys will likely hash to different servers. It's like restarting all of
> your nodes at the same time."
>
> With a consistent hashing algorithm, node removal will not invalidate your
> cache, causing much less of an issue should you need to remove a node from
> the server pool.


So basically, by default, if a memcache server crashes, all caches that were
kept there will continue to be invalid, until that IP comes back up?  Or
will it be re-routed elsewhere when the application sees it not being there
and tries to recreate it?

Which consistent hash library is recommended to rectify this situation, if
any?







On 10/22/07, Rob Sharp <rob.sharp at thesoundalliance.net> wrote:
>
> On Mon, 2007-10-22 at 13:53 +0800, K J wrote:
>
> In our case, not really. It really depends on your current caching
> codebase. The only problem is the (current) lack of a consistent hashing
> algorithm [1] but YMMV.
>
>
>
> What is the consistent hashing part and why is it a bad thing?
>
>
> The wiki explains the issue pretty well:
>
>
> http://www.socialtext.net/memcached/index.cgi?faq#how_does_memcached_handle_failover
>
> "With default clients *adding or removing* servers will invalidate all of
> your cache! Since the list of servers to hash against has changed, most of
> your keys will likely hash to different servers. It's like restarting all of
> your nodes at the same time."
>
> With a consistent hashing algorithm, node removal will not invalidate your
> cache, causing much less of an issue should you need to remove a node from
> the server pool.
>
> Hope that helps,
> Rob.
>     *Rob Sharp*
> Development Lead
>
> *telephone:* 02 9282 4038
> *facsimile:* 02 9282 4099
> *skype:* qu4nnum
>
>
>
>
>  Sound Alliance
> inthemix : FasterLouder : Thought By Them : SameSame
> "Poor workers blame their tools. Good workers build better tools. The best
> workers get their tools to do the work for them." -- Syndicate Wars
>
> 100% recycled electrons were used for the composition of this email
> - please don't print it unless you need to!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20071024/04141288/attachment.htm