[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