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" <[EMAIL PROTECTED]> wrote: > On Fri, Mar 14, 2003, Eric Siegerman wrote: > > > On Wed, Mar 05, 2003 at 10:39:21AM -0500, [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] > www.engelschall.com > > > > _______________________________________________ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
