-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Branko Čibej wrote:
> Peter Samuelson wrote:
>
>> I'm having trouble finding anyone who knows enough about Berkeley DB to
>> give me solid answers here,
The instructions in the official BDB docs for going 4.2 -> 4.3 may be
summarized as:
db4.2_recover
Make complete backup
Open database normally with 4.3 code.
>> so I've got a couple of questions: (1) The
>> README attached below - does it seem accurate and safe? (2a) Is the
>> part about deleting log files (taken from faq.html) necessary,
>
> Yes.
Question for Branko: Why should deleting unused logfiles be necessary?
Desirable to save disc space, yes, but they shouldn't impede the
upgrade... should they?
>> Upgrading a repository to BDB 4.3
>> ---------------------------------
>>
>> Debian subversion packages prior to version 1.2.3dfsg1-3 were compiled
>> to use Berkeley DB 4.2; newer releases use BDB 4.3. If you have
>> created any subversion repositories in BDB format (not the default
>> format, but it was the default prior to subversion 1.1.0), you must
BDB was the default prior to subversion 1.2.0 (not 1.1.0).
>> upgrade them to use BDB 4.3 before subversion will be able to use them.
>>
>> If you try to use a BDB 4.2 repository, you will get an error message
>> including the lines:
>>
>> DB_VERSION_MISMATCH: Database environment version mismatch
>> bdb: Program version 4.3 doesn't match environment version
>>
>> To upgrade the repository, follow the steps below. We shall assume
>> your repository is in /srv/svn/repo1.
>>
>> First make sure the 'db4.2-util' package is installed. Then, ensure
>> that nobody is using or will use the repository while you're updating
>> it. The "mv" commands below will help with this:
>>
>> mv /srv/svn/repo1 /srv/svn/repo1.x
>> lsof +D /srv/svn/repo1.x
>
> This looks like a dangerous thing to do, because one of the still-active
> processes might want to create a new log file and would fail miserably
> in the middle of a transaction.
I would hope that in this circumstance, BDB would simply set the panic
flag in the environment, causing all processes to stop using it ASAP.
Then, the panic and unfinished transactions would be cleaned up by
recovery run below.
I can't point to any specific documentation that states the above is
true, but for a enterprise-class database product to corrupt data due to
a temporary failure to create a file would be a bit ridiculous.
>> Next, make sure the repository databases are in a consistent state
>> (normally they will be, but you are about to destroy the data needed to
>> fix them if they aren't):
>>
>> db4.2_recover -h /srv/svn/repo1.x/db
>>
>> Delete the database "environment":
>>
>> rm /srv/svn/repo1.x/db/__db.???
Unneeded, since a recovery will delete the environment, and not recreate
it unless the -e flag is passed. (svnadmin recover does recreate the
environment, because it opens the repository to print the youngest
revision number after it has done recovery.)
>> Now svnadmin can be used, and if there are any unused database logs,
>> you may as well delete them:
>>
>> svnadmin list-unused-dblogs /srv/svn/repo1.x
In the FAQ, it was the old svnadmin being used at this point. I'm not
saying the new one *won't* work, just that it's not what the FAQ says.
> You can avoid messing with the new svnadmin and do everything with the
> BDB utilities:
>
> 1. db4.2_checkpoint -1 -h /srv/svn/repo1.x/db
> Force a checkpoint of the database environment and logs. This will
> minimize the number of in-use log files after recovery.
> 2. db4.2_recover -h /srv/svn/repo1.x/db
> Recover the database
> 3. db4.2_archive -d -h /srv/svn/repo1.x/db
> Delete unused database log files
> 4. rm /srv/svn/repo1.x/db/__db.???
>
> Once again, this is something you can write a script for.
Looks good.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDhu+FfFNSmcDyxYARAjLSAJ9XHPZEPm7/zIBq71HqVhJtITOKxgCgogR9
DN1uLSSIdIc+xubji4Eo/mE=
=QppJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 25 12:06:11 2005