Transparent failover and restore?

[Gregory Block]

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.  :)