Transparent failover and restore?
Gregory Block
gblock at ctoforaday.com
Mon Dec 20 00:33:25 PST 2004
On 20 Dec 2004, at 00:09, Kevin A. Burton wrote:
> 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
> ;)
>
All of which is horribly convoluted, and does little more than a
carefully parallelized client couldn't do automatically when a new
server was added to the list.
My opinion on this still hasn't budged; if this is going to get done,
it's a client thing, not a server thing. Filling a server when it
comes up can happen on data retrieval *by the client*, *in a parallel
thread*.
I can't see any reason here to add this stuff to a server, given that
we all seem to value the fact that it never falls over; one of the
reasons it never falls over is because it doesn't bloody do anything,
does it. :)
More information about the memcached
mailing list