[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Repository failover

From: Eric Siegerman
Subject: Re: Repository failover
Date: Fri, 14 Mar 2003 13:36:17 -0500
User-agent: Mutt/1.2.5i

On Wed, Mar 05, 2003 at 10:39:21AM -0500, address@hidden wrote:
> I'm looking for gotchas and best practices in implementing a failover
> repository for CVS. The idea would be to use rsync or something similar to
> copy the contents of a repository to a failover server with the cvspserver
> entry disabled in /etc/xinetd.d (RedHat 7.3 servers). In the case of
> failure of the primary server, the cvspserver entry would be enabled on the
> failover server to allow access to the copy of the repository. Obviously,
> this would not prevent local clients on the failover server from
> potentially modifying the copy but such changes would be overwritten on a
> subsequent rsync anyway.

A few issues (I don't have answers to any of these, I'm afraid --
I wish I did!):
 1. Ideally, the rsync (or whatever) should be synchronized with
    CVS itself, so that the failover server has a consistent
    snapshot (no half-done commits, half-applied tags, etc).  But
    for a large repo, that would (a) significantly slow down
    taking the snapshot, due to the nature of CVS's locking
    scheme, and (b) stall user commits for perhaps-unacceptably
    long times

 2. The failover repo will sometimes (usually?) be out of date.
    What happens to sandboxes that have already updated to rev.
    1.9 of some file, when they have to switch over to a backup
    repo that only has 1.8?  

 3. You'll need a plan in place for merging the two repos when
    the main system comes back online.  Someone might well commit
    a revision of that same file to the backup repo; now you have
    two 1.9's (not that important per se), whose contents might
    have diverged (very important).

Of course there's a tradeoff between (1) on the one hand and (2)
and (3) on the other, based on how frequently you take snapshots.


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
A distributed system is one on which I cannot get any work done,
because a machine I have never heard of has crashed.
        - Leslie Lamport

reply via email to

[Prev in Thread] Current Thread [Next in Thread]