[881] in arla-drinkers
RE: Replicated servers, milko?
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Fri Jun 18 18:18:19 1999
From owner-arla-drinkers@stacken.kth.se Fri Jun 18 22:18:18 1999
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 4574 invoked from network); 18 Jun 1999 22:18:17 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 18 Jun 1999 22:18:17 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id AAA19539
for arla-drinkers-list; Sat, 19 Jun 1999 00:12:35 +0200 (MET DST)
Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161])
by sundance.stacken.kth.se (8.8.8/8.8.8) with SMTP id AAA19534
for <arla-drinkers@stacken.kth.se>; Sat, 19 Jun 1999 00:12:31 +0200 (MET DST)
Received: from AFSTEST-2.FAC.CS.CMU.EDU by minbar.fac.cs.cmu.edu id aa27107;
18 Jun 99 18:12 EDT
Date: Fri, 18 Jun 1999 18:09:51 -0400
From: Jeffrey Hutzelman <jhutz+@cmu.edu>
To: Lyle Seaman <LSeaman@stormsystems.com>, arla-drinkers@stacken.kth.se
Subject: RE: Replicated servers, milko?
Message-ID: <2016455884.929729391@AFSTEST-2.FAC.CS.CMU.EDU>
In-Reply-To: <B5C3AE5DDF77D211BD2500A0C9D3A6A11BFFD6@fs1.stormsystems.com>
Originator-Info: login-token=Mulberry:01/GsWembTi+5ItpX9Qe2H3IfQgqc+5J5ymXnt/NmSA/zefOs=;
token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry (Win32) [1.4.1, s/n S-100002]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
On Friday, June 18, 1999, 5:51 PM -0400 Lyle Seaman
<LSeaman@stormsystems.com> wrote:
> It depends on how stringent you want your synchronization semantics to be.
> If you want guaranteed read-write replication, the client has to keep
> track of changes until the changes become "durable", in whatever form
> that takes. At present, "durable" simply means resident in the sole
> server's buffer cache. If you use a quorum model of durability, then the
> client has to keep track of all the changes until the quorum is reached.
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).
> Yes, that's the Sprite and DFS model. The problem with doing only that in
> AFS is that the maximum callback interval is 4.5 hours. Forcing servers
> to be effectively read-only for the first 4+ hours of uptime is untenable.
> Even with the DFS model, the server goes through a "token recovery period"
> for a few minutes during which it is less than completely useful. For
> maximal availability, that recovery period needs to be minimal.
Yes, I agree. I wasn't aware that the maximum callback interval was quite
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.
-- Jeff
