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

Re: Frequent database corruption

From: Mark Benedetto King <mbk_at_lowlatency.com>
Date: 2005-02-19 16:11:48 CET

On Sat, Feb 19, 2005 at 10:32:49AM +0100, Michel Jouvin wrote:
> >
> >The first corruptions we experienced generally occurred during commit,
> >especially on large repositories. When we looked at possible causes for
> >these corruptions, we found that one reason was we were running 2 Apache
> >servers on 2 different nodes in a cluster configuration (cluster file
> >system, no NFS involved). We shut down one of the server and it more or
> >less solved the corruption during commits. This remains strange as the
> >cluster file system has a pure local file system semantics and we never
> >experienced such problems with other databases or other Db usage.
> >

Which cluster filesystem?

> >Now we experienced corruptions not related to any repository write. We
> >have log files showing successful repository access through HTTP GET
> >followed by a GET failure due to database corruption without any
> >repository modification in between and without any Apache
> >problem/restart. We suspected that these corruption were related to
> >Apache restart during a transaction but we now have evidence that
> >corruption can occur at any time without any repository modification. We
> >have Apache log files and corrupted repository copies.

Is this with two httpd nodes or one?

Is the httpd being used for anything else (CGI, PHP, etc?), or is it
dedicated for mod_dav_svn use?

> >
> >Generally svnadmin recover fails on these corruptions. Sometimes we were
> >able to fix corruptions by recover + verify as documented in a note. We
> >also have a directory that we restored from backup and needed to repair
> >before having it accessible again. In this case we had to use recover +
> >verify. And verify + recover definitly corrupts the repository.

What error message do you get when recover fails?

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 19 16:24:36 2005

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

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