Disclaimer: I'm running a very small repository (~600 files) on a Mac OS
X box, and I'm the only user of the repository, so YMMV.
Have you tried to set up an FSFS based repository (in chapter 5 of the
SVN book)? It may not be appropriate for what you are doing, but it has
worked well for me. Look at table 5.1 and read that whole section in
the book...
The main reason that I mention it is that on an older version of
Subversion (1.0.9), the default BDB install (4.1) was extremely
buggy...as in, I got about 3-4 repository corruptions/week. I switched
over to FSFS and have had no problems since then (although I do still do
dumps and backups on a regular basis). If you do decide to go this
route though, do lots of tests first; I don't want to be the guy that
caused a repository thats that big to be corrupted...
Thanks,
Cem Karan
> -----Original Message-----
> From: Peter Kahn [mailto:pkahn@connected.com]
> Sent: Tuesday, December 14, 2004 8:39 AM
> To: kfogel@collab.net
> Cc: users@subversion.tigris.org
> Subject: RE: <?> Deltify, huh, what is it good for<?>
> Questions on Deltify and recovery
>
>
> I actually saw a bit of a difference between the time it
> takes to perform a recovery before and after a deltify, but I
> cannot be sure because I lack a fool proof method of
> introducing corruption into my repository.
>
> I have a repository that is 5.5 GB with about 2 GB of that
> as unused DB log files. Recovery for me takes about 16
> hours. Here are my stats:
>
> Server:
> Linux 2.4.20-8
> 2.6 GHz Processor
> 1 GB Ram
> Stripped and Mirror disk
>
>
> Svn 1.1.1 (r11581)
> Berkeley DB 4.2.52
>
> -----------------------
>
> I really just want to find a means of limiting my downtime.
> We have begun to banter around the idea of running two
> repositories where one is essentially a mirror served by a
> second instance of svnserve and a hook script ferries
> transactions across. Should we have a crash that corrupts
> the database, the primary would be moved out and the
> secondary would become the primary. This would mean all
> users would need to do the switch command with the repository setting.
>
> How do people deal with this problem, are they using hotcopy
> after each transaction? Or some other means to allow a roll
> back prior to the corruption or is 16 hours an unusually long
> time for a recovery.
>
>
> In addition, I find the lack of any useful statistics when
> recovery is needed to be a real problem. I cannot gage how
> long the press will take and I cannot tell what it might be doing.
>
>
> -----Original Message-----
> From: kfogel@newton.ch.collab.net [mailto:kfogel@newton.ch.collab.net]
> On Behalf Of kfogel@collab.net
> Sent: Monday, December 13, 2004 11:51 AM
> To: Peter Kahn
> Cc: users@subversion.tigris.org
> Subject: Re: <?> Deltify, huh, what is it good for<?>
> Questions on Deltify and recovery
>
> "Peter Kahn" <pkahn@connected.com> writes:
> > Here is the real question. I have read some posts on other lists
> about
> > how running deltify can be a useful maintenance operation. I have
> found
> > the description of what deltify does to be a little Spartan for my
> > tastes and I'm just not sure if it would procude any kind of gain.
> >
> > If I run deltify on a daily basis, would it make a recovery faster?
> If
> > I should be running deltify regularily, should it be run
> just on HEAD
> or
> > should it be run on ALL revisions since the last time
> deltify was run?
>
> Unfortunately, 'svnadmin deltify' is not useful these days
> (it's basically a no-op), and won't make recoveries faster.
>
> In the dev@ list, we're discussing steps we can take to make
> Subversion's interactions with Berkeley DB more stable (I
> hasten to point out that the problems appear to be with
> Subversion's usage of BDB, not with BDB itself). We're
> getting a lot of help from the folks at Sleepycat.com. See
> this thread
>
> http://subversion.tigris.org/servlets/BrowseList?list=dev&by=t
hread&from
=266797
for more.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 14 16:49:53 2004