Re: Repository failover

[Ralf S. Engelschall]

On Fri, Mar 14, 2003, Eric Siegerman wrote:

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

I think it is not reasonable to really trying to establish a full
read/write backup repository, because CVS does not easily support
merging of repositories. You would have to create your own ,v file
merging approach. Additionally, I don't think it usually is really
necessary to provide write access to a backup repository. It should be
sufficient that people still can checkout, perform difference and update
operations and just cannot temporarily commit.

Because in a development cycle the commit operations are just around
10% of all CVS repository operations. The most operations are update
and difference operations in my experience. So I recommend you to focus
more on a read-only backup repository -- which in especially trivial to
setup.
                                       Ralf S. Engelschall
                                       address@hidden
                                       www.engelschall.com