?HOWTO:Get over subversion’s DB_VERSION_MISMATCH error

After running several updates on a particular server during the weekend, this morning I got a report that svn was down. a quick insection of libapache2-svn error log turned out this error message:

[Mon Aug 21 12:24:18 2006] [error] [client 172.26.0.73] (20014)Error string not specified yet: Berkeley DB error for filesystem /var/lib/svn/db while opening environment:\nDB_VERSION_MISMATCH: Database environment version mismatch
[Mon Aug 21 12:24:18 2006] [error] [client 172.26.0.73] Could not fetch resource information.  [500, #0]
[Mon Aug 21 12:24:18 2006] [error] [client 172.26.0.73] Could not open the requested SVN filesystem  [500, #160029]
[Mon Aug 21 12:24:18 2006] [error] [client 172.26.0.73] Could not open the requested SVN filesystem  [500, #160029]

After googling it I found out that this has been reported as Debian Bug#342508, which promptly refers you to read /usr/share/doc/subversion/README.db4.3.gz. The recipe works just fine, and I reproduce it here for completeness:

# cd /var/lib
# mv svn svn-maint
# cd svn-maint/db
# db4.2_checkpoint -1
# db4.2_recover
# db4.2_archive
# svnlook youngest ..
# db4.3_archive -d
# cd /var/lib
# chown -R www-data.www-data svn-maint
# mv svn-maint svn

In the same document there’s a note that recommends to migrate the repository from DBD to FSFS. Since I’ve seen some serious trouble with OpenLDAP’s Berkeley DB backend before and the SVN database is over 1GB right now, I’ll schedule a mainteinance window for this migration ASAP.

[tags]Subversion, Debian, BerkeleyDB[/tags]

6 thoughts on “?HOWTO:Get over subversion’s DB_VERSION_MISMATCH error”

  1. Thanks for this entry! You saved my life! ;-)
    I thought all my data was already lost….

  2. Thanks also, didn’t think everything was lost but sure made fixing much quicker…

  3. For me running
    svnadmin recover /path/to/db
    was enough

Comments are closed.