Transparent failover and restore?
Kevin A. Burton
burton at newsmonster.org
Sun Dec 19 16:00:50 PST 2004
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.
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
More information about the memcached