[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Antwort: Keeping a hot/live FSFS repo for failover [Virus checked]

From: <andreas.kollenbach_at_t-mobile.at>
Date: 2006-10-17 09:59:11 CEST

Hi Kyle,

Which version of Subversion do you use?

With Subversion 1.4 the new tool svnsync should solve your problem much
more easier.
Also run frequently small amount of data shall be synchronized between both


             "Kyle Kline"
             .com> An
             17.10.2006 04:49 Kopie
                                        Keeping a hot/live FSFS repo for
                                        failover [Virus checked]


I'm implementing an SVN repository with a failover on a sibling server
(100mbs LAN), built to do failover very very quickly (two identically
configured SVN services, with load balancer directing traffic at the

Backup repo would be seeded with an svnadmin hotcopy. Also can assume that
revprops would never ever change for old revs.

My plan for a script to keep the secondary in 'hot' backup state is
basically (pseudocode):
       copy \\server-1\svn\repoA\db\current
       primary_youngest = svnlook \\server-1\svn\repoA
       secondary_youngest = svnlook \\server-2\svn\repoA
       syncrev = secondary_youngest + 1
       while(syncrev <= primary_youngest)
            copy \\server-1\svn\repoA\db\revs\{{syncrev}}
            copy \\server-1\svn\repoA\db\revprops\{{syncrev}}
       copy \\server-2\svn\repoA\db\current.tmp current /Y (avoid

This would be run very frequently so would never pick up more than a few
revs at a time. Is this reasonably correct? esp wrt to getting a copy of
"current" prior to initiating rev-by-rev copy -- so 'current' file updated
is the one that happened before we copied te rev data over.

If the primary failed, the traffic would be routed to secondary
immediately. When bringing the primary back online, this sync would be run
in reverse, then traffic routed to primary again.

Any thoughts? Anyone else doing something similar?


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 17 10:00:07 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.