Replicated servers, milko?

Lyle Seaman LSeaman at stormsystems.com
Mon Jun 21 15:24:31 CEST 1999


> Or you can do what Ubik does - let the master server be reponsible for
> contacting a quorum, and simply return an error to the client if an
> operation fails without a quorum being reached.  The advantage to this
> approach is that it could probably be done in such a way that 
> unmodified
> clients would continue to work (of course, clients that want 
> to take full
> advantage of R/W replication would have to understand the semantics of
> multiple R/W sites in the VLDB).

Right, this is what I said, except you're describing the error case
("durability" is not acheived, so fail).  The decision whether to make the
client contact multiple replicas directly or whether to let a "master"
server manage them is a design tradeoff between various factors.  Using a
master server might well be simpler, as you say.

> that large.  The other thing you could do is have the new master
> reinitialize the callback state on each cilent it hears from. 
>  This would
> have the same effect as if a single server crashed, 
> recovered, and took an
> update, all between the time a long callback was granted and when the
> client in question tried to talk to the server again.

You could.  It just depends on what semantics you want to provide.  It's my
belief that people who really care about read-write replication also really
care that failover from one replica to another occur without data loss in
the middle.  If it were up to me (which it ain't, obviously :-) I'd take the
opportunity of adding this read-write replication and use it to close up
that hole that you hinted at above -- using the same technique of
synchronously logging new host creation events.  Kill two birds with one
stone.  If you're reeling at the performance implications of doing a
synchronous disk write for every new client, you could use a hybrid
approach.  This problem is far easier to solve than the problem of
propogating the file data through a heterogenous network in minimal time,
and then working out what semantics get provided in conjunction with
disconnected operations.

Sigh, this is all moot.  Unless I win the lottery, I'm not going to be able
to implement it.






More information about the Arla-drinkers mailing list