Transparent failover and restore?

[Kevin A. Burton]

John McCaskey wrote:

>Client performs hash to determine server to put key in (just like it
>does now), client puts key/value pair into cache.  Client then performs
>some kind of second hash that gurantees a different server is selected
>and puts key/value pair into another servers cache.
>
>The only requirement now left is to ensure that as servers are
>added/removed or go up/down the hashing always comes up with the same
>server.  There are a number of ways to do this, which I won't get into
>here.  You obviously add both extra cache memory usage, and extra
>network bw usage by doing this, but in some cases it may be worth it.
>  
>
This isnt' a bad idea but would require 2x the storage across the 
cluster.  And yes the issue would be to route the failover get() query 
when the nodes in the cluster are down.   This shouldn't be hard.  You 
could just rotate the key space by one...

So if you have two servers...  and an object with server 1 you'd store 
the backup in server 0... if its 0 you store it in 1. and so on.

A secondary drawback is that now all set() operations take twice as long 
but if you only serialize once you can save on local CPU time so you're 
just talking about network IO.

Kevin

-- 

Use Rojo (RSS/Atom aggregator).  Visit http://rojo.com. Ask me for an 
invite!  Also see irc.freenode.net #rojo if you want to chat.

Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html

If you're interested in RSS, Weblogs, Social Networking, etc... then you 
should work for Rojo!  If you recommend someone and we hire them you'll 
get a free iPod!
    
Kevin A. Burton, Location - San Francisco, CA
       AIM/YIM - sfburtonator,  Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412