Handling failovers (rewrite)

Ben Manes ben_manes at yahoo.com
Wed Jul 4 04:03:43 UTC 2007

I'm curious as to the recommended solution for recovering from a
failed memcached node.  I've read other threads posing this question,
but responses haven't included implemented solutions or how large
build-outs manage this situation.  For example, see:

 - http://lists.danga.com/pipermail/memcached/2006-June/002408.html

 - http://lists.danga.com/pipermail/memcached/2006-October/002922.html

I'm using the standard Java client which, like most clients, supports
auto-failover support.  I don't quite understand how this works since
my understanding is that the server (bucket) is chosen by hashing the
keys and modding by the server list.  It also doesn't seem like
dynamically updating the server list is supported, which other threads
have touched on.  Could someone explain the built-in failover support
and how robust it is?

Disregarding the built-in mechanism, I see two obvious solutions I could layer on top of the client.

  #1: Use a backup pool.  If a request returns a miss, then request from the backup.  If it hits, then the toggle the ordering.

  #2: Use a pseudo, non-guaranteed stripping like a approach where
every incoming key is transformed into N keys.  Those keys could be
requested in single or multi-get fashion.  One would assume that there
is a 1/N chance that all of the keys would map to the same failed

I'd like to know how others have handled this issue.  When a server comes back up, do you attempt to rewarm it?



P.S. Again, sorry about the failed message earlier.  Firefox seems to send, Opera does not.

Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070703/0a5efa39/attachment.html

More information about the memcached mailing list