<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Actually, minor correction. I meant to state that there is a 1/M chance that all N keys would map to the same server, if my understanding of how the buckets are chosen is correct.<br><br>Thanks.<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Ben Manes <ben_manes@yahoo.com><br>To: memcached@lists.danga.com<br>Sent: Tuesday, July 3, 2007 9:03:43 PM<br>Subject: Handling failovers (rewrite)<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div><div>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:<br><span>
- <a rel="nofollow" target="_blank" href="http://lists.danga.com/pipermail/memcached/2006-June/002408.html">http://lists.danga.com/pipermail/memcached/2006-June/002408.html</a></span><br><span>
- <a rel="nofollow" target="_blank" href="http://lists.danga.com/pipermail/memcached/2006-October/002922.html">http://lists.danga.com/pipermail/memcached/2006-October/002922.html</a></span><br>
<br>
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?<br><br>
Disregarding the built-in mechanism, I see two obvious solutions I could layer on top of the client.<br>
#1: Use a backup pool. If a request returns a miss, then request from the backup. If it hits, then the toggle the ordering.<br>
#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
server.<br>
<br>
I'd like to know how others have handled this issue. When a server comes back up, do you attempt to rewarm it?<br>
<br>
Thanks,<br>
Ben<br>
<br>
P.S. Again, sorry about the failed message earlier. Firefox seems to send, Opera does not.<br>
</div></div></div><br>
<hr size="1"><a rel="nofollow" target="_blank" href="http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html">Sucker-punch spam</a> with award-winning protection.<br> Try the <a rel="nofollow" target="_blank" href="http://us.rd.yahoo.com/evt=49981/*http://advision.webevents.yahoo.com/mailbeta/features_spam.html">free Yahoo! Mail Beta.</a></div><br></div></div><br>
<hr size=1>Don't be flakey. <a href="http://us.rd.yahoo.com/evt=43909/*http://mobile.yahoo.com/mail">Get Yahoo! Mail for Mobile</a> and <br><a href="http://us.rd.yahoo.com/evt=43909/*http://mobile.yahoo.com/mail">always stay connected</a> to friends.</body></html>