Re: Repository failover

[Mark]

Haven't looking into this much, but if CVSup can send based on date, maybe it
can be used to assist failover. Any thoughts from those that have used/are
using CVSup?

For example (active means cvs server working for users):
=====================================================

Normal operations:
(primary active server k  (->-> CVSup active ->->) failover inactive server G)

Primary down, failover active:
(primary inactive server k (--- CVSup inactive---) failover active server G)

---- Maybe two options to recover from primary going down

Option 1: get server k back up as primary:
- take cvs offline to users on both servers K&G
(primary inactive server k  (<-<-CVSup active time based <-<-) failover
inactive server G)
- after completed resync, return to nomal ops
(primary active server k  (->-> CVSup active ->->) failover inactive server G)

Option 2: switch roles of server K & G
failover inactive server k  (<-<- CVSup active <-<-) primary active server G

I am going to start to looking at possible rollover/reduncancy for primary CVS
server failure soon. From this thread, it looks like other that backups, it
isn't done that often for CVS.

If setting up a failover is something that can be done with CVS, how do all the
clients start using the new server?

Mark

--- "Ralf S. Engelschall" <address@hidden> wrote:
> 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
> 
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com