Thanks for the excellent answers to my question! One more comment and question below.
On Tue, Aug 19, 2014 at 12:05 AM, Branko Čibej <br...@wandisco.com> wrote: > On Mon, Aug 18, 2014 at 7:43 PM, Eric Johnson <e...@tibco.com> > <e...@tibco.com> wrote: > > I've got a crazy idea for minimizing downtime - since the servers are not > being constantly bombarded with commits, I'm thinking that I can just do a > dump/load on the fly, and see if any commits came in while the dump was > happening, and if they did, try the dump again. > > That is: > > STARTREV = `svnlook youngest repodir/$REPONAME` > svnadmin create reload/$REPONAME > svndump repodir/$REPONAME | svnadmin load reload/$REPONAME > ENDREV = `svnlook youngest repodir/$REPONAME` > if "$STARTREV" == "$ENDREV"; then > mv repodir/$REPONAME older/$REPONAME > mv reload/$REPONAME repodir/$REPONAME > fi > # and if the above didn't match, repeat the above until success. > > There's the tiniest bit of a race condition at the very end. But is it safe > to do an svnadmin dump on a live repository? > > > Dumping a live repository is perfectly safe. When the first (complete) > dump and load finish, you don't have to retry the whole dump if there were > any commits to the source repository; just do an incremental dump and > incremental load. > I just did a timed comparison of an svndump versus svnsync. svndump was over 10x faster for my test case (20 min vs. 260 min). So I'll follow the dump approach. > > In other words: > > 1. Perform a full dump from [old] and load into [new] > 2. Make [old] read-only > 3. If there were any commits during (1), perform an incremental dump > from [old] and load into [new] > 4. Switch the repositories and restart the server to purge in-memory > caches. > > The solution with svnsync is similar, except that instead of running > 'svnadmin dump/load' you'll run 'svnsync'. > > Both solutions have a downside: they will not notice revision property > changes (e.g., log message changes) in revisions that have already been > synced to the new repository. There are ways to solve that, but by far the > easiest way is to block revprop changes in the pre-revprop-change hook in > the old repository while you're doing the upgrade. > > Just remember to always restart the server after switching from the old to > the new repository to remove stale caches. (Yes, we're currently working on > making that mostly unnecessary in 1.9.) > What are these caches? I've got memcached turned off for these (fsfs) repositories. What, exactly, do I need to restart? All client access is via HTTP. Restarting Apache for each of my repository updates would be unfortunate, because I want to keep the number of times I bounce the server to a low value, even if it does only take 3s to restart. It is one thing for me to take an individual repository off-line for 1-5 seconds while I swap and do an incremental load, but it is another if I take all 80+ repositories offline repeated. Has anybody ever published a script that loops through a bunch of repositories, and dump/loads, moves the old repository aside, does an incremental dump/load, copies over existing hook scripts, and then moves the new copy into place? I didn't see anything obvious in the "contrib" sources. Eric
