You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2005/05/05 21:20:09 UTC
Re: Upgrading BDB repositories on Win32
Philip Martin wrote:
>The upgrade procedure that seems to work on my test repository is:
>
>- run 'svnadmin recover' using BDB 4.2
>- remove db/_db.00?
>
>
Well, there's a bug right there in "svnadmin recover", then. It should
remove the environment files itself.
>- remove or archive db/log.*
>
>
Ouch! This is *not* good.
>Then just start using BDB 4.3, there is no need to run a 4.3 recover
>although it doesn't do any harm. Note that I have to remove all the
>log files, even those not designated "unused", I don't know under
>what circumstances this is safe.
>
>
Never, according to the BDB docs.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Upgrading BDB repositories on Win32
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko ÄŒibej <br...@xbc.nu> writes:
>
>
>
>>Philip Martin wrote:
>>
>>
>>
>>>The upgrade procedure that seems to work on my test repository is:
>>>
>>>- run 'svnadmin recover' using BDB 4.2
>>>- remove db/_db.00?
>>>
>>>
>>>
>>Well, there's a bug right there in "svnadmin recover", then. It should
>>remove the environment files itself.
>>
>>
>
>svn_repos_recover2() does remove the environment, however
>'svnadmin recover' open the recovered repository to read the
>youngest revision and so the environment is recreated.
>
>
Ah. You're right, I missed that part. So /that/ is the bug in "svnadmin
recover". It's sheer nonsense keep the old-format environment files
around when you recover the database, becasue that will always make the
newer version of BDB choke. In other words, "svnadmin recover" as it
stands now is useless for upgrading BDB repositories.
>>>- remove or archive db/log.*
>>>
>>>
>>>
>>>
>>Ouch! This is *not* good.
>>
>>
>>
>>>Then just start using BDB 4.3, there is no need to run a 4.3 recover
>>>although it doesn't do any harm. Note that I have to remove all the
>>>log files, even those not designated "unused", I don't know under
>>>what circumstances this is safe.
>>>
>>>
>>>
>>Never, according to the BDB docs.
>>
>>
>
>4.3 recovery doesn't work with 4.2 log files, even using native BDB
>tools.
>
Yes. But read my other post: The DB docs say to recover with the old
version, but _not_ with the new version, and to leave the logs alone.
Just remove the unused logs, and start using the database. I suppose
that's why doing "svnlook youngest" before using the new svnadmin
recover usually works.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Upgrading BDB repositories on Win32
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> Philip Martin wrote:
>
>>The upgrade procedure that seems to work on my test repository is:
>>
>>- run 'svnadmin recover' using BDB 4.2
>>- remove db/_db.00?
>>
> Well, there's a bug right there in "svnadmin recover", then. It should
> remove the environment files itself.
svn_repos_recover2() does remove the environment, however
'svnadmin recover' open the recovered repository to read the
youngest revision and so the environment is recreated.
>>- remove or archive db/log.*
>>
>>
> Ouch! This is *not* good.
>
>>Then just start using BDB 4.3, there is no need to run a 4.3 recover
>>although it doesn't do any harm. Note that I have to remove all the
>>log files, even those not designated "unused", I don't know under
>>what circumstances this is safe.
>>
> Never, according to the BDB docs.
4.3 recovery doesn't work with 4.2 log files, even using native BDB
tools. Using BDB 4.2:
$ db4.2_recover -h repo/db/
$ ls repo/db
DB_CONFIG format locks nodes strings
changes fs-type log.0000000001 representations transactions
copies lock-tokens log.0000000002 revisions uuids
$ db4.2_archive -h repo/db/
log.0000000001
$ rm repo/db/log.0000000001
Switch to BDB 4.3:
$ /usr/local/bdb43/bin/db_recover -h repo/db
db_recover: Skipping log file repo/db/log.0000000002: historic log version 8
db_recover: repo/db/log.0000000003: log file open failed: No such file or directory
db_recover: PANIC: No such file or directory
db_recover: DB_ENV->log_put: 3: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: dbenv->close: DB_RUNRECOVERY: Fatal error, run database recovery
$ ls repo/db
DB_CONFIG format locks representations transactions
changes fs-type log.0000000002 revisions uuids
copies lock-tokens nodes strings
$ rm repo/db/log.0000000002
$ /usr/local/bdb43/bin/db_recover -h repo/db
$ ls repo/db
DB_CONFIG format locks representations transactions
changes fs-type log.0000000001 revisions uuids
copies lock-tokens nodes strings
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Upgrading BDB repositories on Win32
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
> Philip Martin wrote:
>
>> The upgrade procedure that seems to work on my test repository is:
>>
>> - run 'svnadmin recover' using BDB 4.2
>> - remove db/_db.00?
>>
>>
> Well, there's a bug right there in "svnadmin recover", then. It should
> remove the environment files itself.
And I've found that bug. We were passing both "DB_INIT_LOCK" and
"DB_PRIVATE" when opening the environment for recovery. db_recover does
one _or_ the other, but never both. It uses DB_PRIVATE when it doesn't
want to retain the environment files (and we never want to do that).
>
>> - remove or archive db/log.*
>>
>>
> Ouch! This is *not* good.
The BDB docs say this:
If the application has a Berkeley DB transactional environment, and the
log files need upgrading but the databases do not, the application may
be installed in the field using the following steps:
1. Shut down the old version of the application.
2. Run recovery on the database environment using the DB_ENV->open
<ci...@xbc.nu> method or the db_recover
<ci...@xbc.nu> utility.
3. Remove any Berkeley DB environment using the DB_ENV->remove
<ci...@xbc.nu> method or an appropriate
system utility.
4. Archive the database environment for catastrophic recovery. See
Archival procedures <ci...@xbc.nu> for more
information.
5. Recompile and install the new version of the application.
6. Restart the application.
Step 3. should be happening automatically, but this says nothing about
removing log files that are in use. So I guess doing "svnadmin recover"
and removing the environment files should be enough.
I'll fix svnadmin recover, of couse, and propose the change for backport
to 1.1.x.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org