[889] in arla-drinkers
RE: Replicated servers, milko?
daemon@ATHENA.MIT.EDU (Lyle Seaman)
Mon Jun 21 09:30:48 1999
From owner-arla-drinkers@stacken.kth.se Mon Jun 21 13:30:47 1999
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 2915 invoked from network); 21 Jun 1999 13:30:46 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 21 Jun 1999 13:30:46 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id PAA12073
for arla-drinkers-list; Mon, 21 Jun 1999 15:24:31 +0200 (MET DST)
Received: from gw.stormsystems.com (stormsystems.com [209.49.190.30])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id PAA12069
for <arla-drinkers@stacken.kth.se>; Mon, 21 Jun 1999 15:24:24 +0200 (MET DST)
Received: from fs1.office.stormsystems.com (exchange.office.stormsystems.com [172.29.1.5])
by gw.stormsystems.com (8.9.3/8.9.1) with ESMTP id JAA19192
for <arla-drinkers@stacken.kth.se>; Mon, 21 Jun 1999 09:23:32 -0400
Received: by fs1.stormsystems.com with Internet Mail Service (5.5.2448.0)
id <NBCRA3ZX>; Mon, 21 Jun 1999 09:23:31 -0400
Message-ID: <B5C3AE5DDF77D211BD2500A0C9D3A6A11BFFD8@fs1.stormsystems.com>
From: Lyle Seaman <LSeaman@stormsystems.com>
To: arla-drinkers@stacken.kth.se
Subject: RE: Replicated servers, milko?
Date: Mon, 21 Jun 1999 09:23:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
> 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.
