Transparent failover and restore?

Kevin A. Burton burton at
Sun Dec 19 16:09:08 PST 2004

Josh Berkus wrote:

> I can see that this would be relatively easy to implement on the 
> client side;
>I can also see room for a server-side daemon that manages it.  Doing it on 
>the client side, while relatively easy to hack, has the disadvantage of 
>making the server lists maintainence problem even worse.  
>I really think there's room for a server-side process that manages the hash 
>key distribution of items.    One client of mine already shot down the use of 
>memcached for a project because we don't have this.
Then you couldn't do client side key routing... which is an advantage.

I think the major problem is that the servers are dumb and just know 
about their individual server state and not the WHOLE state.

The only reason the client should have a hard wired or configured server 
name list is just for node bootup.

If clientA only know about serverA, and serverB then when serverC is 
added you'll have to have a bunch of wasted memory on serverA and 
serverB and then a bunch of cache misses (which are probably slow) would 
be needed to init serverC.

Instead clientA would connect to either serverA or serverB and then 
retrieve the authoritative server list.  At t0 this would just be 
{serverA, serverB} but at t1 (after serverC was added) then it would be 
{serverA, serverB, serverC}.  Then serverA, and serverB would just move 
their entries to serverC and then delete them to free up memory.

Which seems to make sense. The problem is that as soon as serverC is 
initialized you'd need to notify the client of its reconfiguration but 
this could be a protocol extension as any part of fetch/set...

But then maybe this is what you meant by "a server-side process that 
manages the hash distribution of items" and I was just being verbose ;)



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

Rojo is Hiring! -

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 -
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412

More information about the memcached mailing list