You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by kf...@collab.net on 2005/07/01 14:07:50 UTC
Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
kfogel@collab.net writes:
> Instead, you should try using Berkeley's 'db_recover' utility first,
> passing it the '-c' option, meaning "perform catastrophic recovery".
> (See http://www.sleepycat.com/docs/utility/db_recover.html.)
>
> Make sure nothing else is accessing the repository when you do it.
>
> I'm surprise to find that there is no way to tell 'svnadmin recover'
> to do a catastrophic recovery, and that we don't seem to have a FAQ
> item on this. I'll try to do something about the latter, at least.
Okay, we have information about this in our FAQ now, see
http://subversion.tigris.org/faq.html#wedged-repos
(or rather, see it five minutes from now, when the live site gets the
updates I just committed :-) ).
Let us know if db_recover helped you at all.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Posted by Jamie Lawrence <ja...@jal.org>.
On Sat, 02 Jul 2005, Saulius Grazulis wrote:
> On Friday 01 July 2005 21:17, kfogel@collab.net wrote:
>
> > Well, until a checkpoint happens (i.e., data is sync'd from log file
> > to database file), the logfiles hold the only copy of actual data. So
> > BDB's sensitivity to logfile corruption is understandable! :-)
>
> To me, this explanation does not sound convincing. Maybe my understanding of
> databases is a bit naive, but shouldn't a serious db that uses transactions
> (and a believe bdb uses them) write a transaction first and only then set a
> bit "transaction finished" in a most-possibly-atomic way? In such setting,
> during a crash one should only loose the last transaction (which for svn
> would mean the last checkin), and end up with the database that is fully
> usable and just misses that last portion of data. What is wrong in this
> picture?
I'll chime in, as a DB junkie. a 'serious' DBMS attempts to be 'atomic',
which is what you're talking about. A transaction either happens, or it
doesn't, come hell or power failure. Implementation-wise, this has
translated into the notion that you record logs first - say what you
meant to do, before you do it, that way if you're interupted, you can
replay the logs.
Now, say, Oracle, plays all sorts of games on every platform they
support to ensure that data gets to disk. The best they can do is to
make sure it gets to the RAID controller/ATA drive/SCSI disk/MD virtual
device cache. Last I heard, they have something like 8000 engineers.
Granted, not all working on the DB. And Larry still peddles "bare iron"
from time to time, attempting to become an OS. And I haven't started
talking about bugs or "unimplemented features". This code base is coming
on 30 years old.
And oracle DBs still become corrupt. If you don't think it is common,
ask me about a mysterious fuc^H^H^Hfailure in 10G bitmap indexing for
which I spent last week trying to correct, and which also baffled the
good people at Oracle support. Not cool. (The best we settled on is,
"if it hurts when you poke there, don't poke there. A patch is in the
mail.")
Granted, BDB is a somewhat more constrained environment, in comparison.
That doesn't constrain the problem set as much as you'd think. If you're
interested, hang out on postgres-dev a bit - I think those folks have
the problem set down, and are doing about the coolest stuff around at
the moment, at least for values of cool, where cool = (cool + in
public).
> So what makes bdb-using-svn rather sensitive to unanticipated breaks in
> processing? Actually, I was always thinking that the only purpose of having a
> sophisticated db managment system is to provide higher reliability that a
> plain filesystem does, not lower...
I believe the issue is in the specific way svn is (ab)using BDB. BDB is
pretty robust, for what it is. For the record, I don't know what,
exactly, the issue is (I'd be very curious to find out). But much like
Oracle, or Postgres, I imagine there's no end to the ways in which you
can abuse it. Using The C libs to interface with any of them, there
are countless ways you can hose a DB. (without even trying: you should
see some of the cool "don't do that" things I learned with the OCI docs
and a compiler. Give me a hammer, and even though I don't see thumbs,
I'll still hit them.) I've never written code against BDB, but I can't
imagine it is any different.
-j, not an svn developer, but very sympathetic.
-- Jamie Lawrence
jal@jal.org "The sign that points to Boston doesn't have to go there."
- Max Scheler
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Posted by Saulius Grazulis <gr...@akl.lt>.
On Friday 01 July 2005 21:17, kfogel@collab.net wrote:
> > Since power had gone down well *after* the last commit to SVN, the
> > only thing that seemed to have gotten corrupt was the log files
> > themselves, and not the db; and it seems (in the few times I've had
> > this type of problem) that BDB is very sensitive to corrupt log files
> > and has difficulty recovering from them.
>
> Well, until a checkpoint happens (i.e., data is sync'd from log file
> to database file), the logfiles hold the only copy of actual data. So
> BDB's sensitivity to logfile corruption is understandable! :-)
To me, this explanation does not sound convincing. Maybe my understanding of
databases is a bit naive, but shouldn't a serious db that uses transactions
(and a believe bdb uses them) write a transaction first and only then set a
bit "transaction finished" in a most-possibly-atomic way? In such setting,
during a crash one should only loose the last transaction (which for svn
would mean the last checkin), and end up with the database that is fully
usable and just misses that last portion of data. What is wrong in this
picture?
So what makes bdb-using-svn rather sensitive to unanticipated breaks in
processing? Actually, I was always thinking that the only purpose of having a
sophisticated db managment system is to provide higher reliability that a
plain filesystem does, not lower...
Sure, I do not mean to say that the bug is necessarily in the bdb library --
it can be in filesystem, kernel, svn -- anywhere... But what about "defensive
programming" and anticipating the ways in which the system is likely to fail,
so that it fails gracefully? Is it at all possible an a database world? ;)
Also, could this incident be related to Dave Camp's corrupted repositories?
(both on MAC OS 10.3, both with bdb backend, both after power failure...
Hmmmm...).
--
Saulius Gražulis
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)
tel/fax: (+370-5)-210 40 05
mobilus: (+370-684)-49802, (+370-614)-36366
Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Posted by Dave Camp <da...@thinbits.com>.
Indeed. One would expect that the purpose of a journaled system is
that if one of the transactions is still in a log file when the
system goes down, it can either be re-commited, or the database
should be able to be rolled back to N-1 as it were.
As I recently discovered, that does not seem to be the case with svn
and bdb. A failure in a log file seems to torch the whole database.
In addition, it's not clear why stuff sits in log files beyond the
end of a session. I would expect that when svnserve is done with the
transaction, the changes would be commited to the main database file.
It's not clear to me how the usage of bdb can be considered safe for
use as a backend. And from the feedback I'm getting on my recent
problems, I'm not the only one thinking this.
Just to be clear, I'm not trying to beat anyone up or lay blame for
my recent problems on the svn developers. svn is a great tool and I
appreciate all the hard work that is put into it. But if bdb is not a
solid solution for storing your source code (and recent postings
suggest it's a time bomb) I think the svn developers should make a
concerted effort to get existing users to switch to fsfs.
Dave
On Jul 1, 2005, at 1:07 PM, Zachary Pincus wrote:
> Wait a second... I thought the whole point of using BDB was that it
> was journaled, and that any transaction was thus guaranteed atomic
> and re-playable (if the transaction was a success).
>
> So, (a) how is it that a commit that happened hours before the
> power went down existed *only* in a log file? And (b), is there a
> way to "play back" all of the non-corrupted transactions? That is,
> if transaction N resides only in the (corrupted) log file but
> everything else is properly journaled/whatever, shouldn't it be
> trivial to restore the DB back to state N-1? It seems really
> unfortunate that if a log file gets corrupted, there's no simple
> way to roll the repository back to the last "usable" state, and
> instead you have to rely on questionable database "recovery" steps
> that apparently don't deal super-well deal bungled logfiles.
>
> Further, as I stated, by deleting the logfile, I was able to
> restore (read-only) functionality to the repository -- *all the way
> up to the latest commit*. So it appears that the real problem
> wasn't that the last commit hadn't been flushed from the log to the
> database, but that BDB had somehow forgotten that it had already
> flushed that and thought that the logfile was still somehow active.
> Is this a separate vulnerability in BDB?
>
> Presumably I am missing some subtleties of how the DB functions. As
> such, I'm not trying to be antagonistic with these questions, but
> just trying to reconcile what I know (mostly from the SVN docs,
> which make strong claims about why BDB is great) with what you're
> telling me now. A deeper understanding of the DB would certainly
> help me get things sorted out!
>
> Thanks for your time,
>
> Zach Pincus
>
>
> On Jul 1, 2005, at 11:17 AM, kfogel@collab.net wrote:
>
>
>> Zachary Pincus <zp...@stanford.edu> writes:
>>
>>> Thanks for putting up this information! Unfortunately, I was never
>>> able to get my original repository fully-recovered. Though, as I
>>> said,
>>> through some miracle I did manage to get it to a state where I could
>>> perform a dump, by playing stupid games with the log files.
>>>
>>> Since power had gone down well *after* the last commit to SVN, the
>>> only thing that seemed to have gotten corrupt was the log files
>>> themselves, and not the db; and it seems (in the few times I've had
>>> this type of problem) that BDB is very sensitive to corrupt log
>>> files
>>> and has difficulty recovering from them.
>>>
>>
>> Well, until a checkpoint happens (i.e., data is sync'd from log file
>> to database file), the logfiles hold the only copy of actual
>> data. So
>> BDB's sensitivity to logfile corruption is understandable! :-)
>>
>> -Karl
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Posted by Zachary Pincus <zp...@stanford.edu>.
On Jul 1, 2005, at 1:28 PM, kfogel@collab.net wrote:
> You're getting into BDB implementation details. BDB is allowed to
> store data anywhere it wants, as long as it doesn't lose it. If the
> way it guarantees things is by storing stuff in logfiles, then that's
> fine -- if you remove a logfile, that's kind of like removing a data
> file, then :-).
Granted. But my point here wasn't about removing logfiles! (Please see
my next email.) It was about the lack of tools to roll-back data to a
previous, valid state. The subversion docs make a lot of claims about
how BDB is great to use because if things get munged up, it's easy to
restore the database to a previous working state. For example, from the
subversion book:
> Berkeley DB is also a very reliable database system. Subversion uses
> Berkeley DB's logging facilities, which means that the database first
> writes to on-disk logfiles a description of any modifications it is
> about to make, and then makes the modification itself. This is to
> ensure that if anything goes wrong, the database system can back up to
> a previous checkpoint -- a location in the logfiles known not to be
> corrupt -- and replay transactions until the data is restored to a
> usable state. See the section called Managing Disk Space for more
> about Berkeley DB logfiles.
This is great and all -- *but how do you actually get subversion to
roll the database back to a consistent state?* Sure, svn recover (and
db_recover -c) try to get the database back to the *latest* state. But
if they fail, they throw up their hands and just say "run database
recovery" like that's not what you were just doing. Thus far, it
appears like subversion provides no tools for rolling back a database
that's been corrupted to the last "clean" state (potentially losing a
commit in the process), despite claims of *this very ability* in the
documentation.
It's reasonable that a logfile might get corrupted when the power goes
out. What's unreasonable is a complete lack of tools to roll back a
corrupted log file, beyond (a) totally black-box "recovery" processes
and (b) my stupidly crude method of just deleting the corrupted file to
"roll it back" which is (as you are at pains to point out) not a very
reliable or general solution to the problem.
This problem has happened to me several times. Once with a power
failure, once with a hard system crash (overheated rack), and once
spontaneously. NEVER has the "recovery" procedure worked for me. Yet
every time I read the SVN docs, all I can see is how great BDB is
because the transactions are logged and journaled. When I read that, I
think that this means that if the system crashes **HOURS AFTER** a
successful commit, I should be able to, at the very least, easily get
the database back to a recent and reasonably consistent state.
Zach Pincus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Posted by kf...@collab.net.
Zachary Pincus <zp...@stanford.edu> writes:
> Sure, deleting a log file is a stupid last ditch idiot thing that I
> tried in a panic. But the fact that it worked may indicate a flaw in
> the logging procedures, and definitely one in the recovery
> procedures. So try to forget how idiotic it was, and focus on what
> this may indicate about db reliability issues.
>
> Finally, note that this is now at least TWO times that I've been able
> to partially fix an "unrecoverable" svn repository by removing
> corrupted logfiles. Thus, I don't think this is some random,
> unrepeatable fluke thing but possibly an actual issue in BDB or how
> SVN and BDB interact.
Well, yes, I hear what you're saying. If time were infinite, this
would be one route to pursue to find bugs and/or potential
improvements in how BDB and Subversion interact. But an even better
route is for us to be working with Sleepycat on making things less
sensitive to misuse in the first place... and there isn't (for me)
time to do both. Heck, I'm too swamped with other stuff to be even
doing that :-). The Subversion developers really carrying the load
there are Mike Pilato and Branko Čibej.
FWIW, it does not necessarily indicate a design flaw that removing a
supposedly unflushed log file can result in no data loss. Sometimes
bits have to be flipped in weird orders in order to prevent race
conditions, and if things crash at the wrong moment, odd states can
happen.
Also keep in mind (and I hate to say this) that a repository that
looks fully recovered could, in fact, have missing or corrupt data in
some subtle way; for example, certain kinds of wonkiness in the
'copies' table would not necessarily cause Subversion to stop working.
So you can't be sure that your recipe succeeded 100%, although I
certainly hope it did!
I realize that all of this is vague and hand-wavy. Diving into the
code takes time; it's easier for both of us to post to the list than
to actually figure out what happened :-). This is one reason
switching to FSFS as the default was a good idea, I think: it's a bit
easier for us to debug.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Posted by Zachary Pincus <zp...@stanford.edu>.
On Jul 1, 2005, at 1:28 PM, kfogel@collab.net wrote:
> You're getting into BDB implementation details. BDB is allowed to
> store data anywhere it wants, as long as it doesn't lose it. If the
> way it guarantees things is by storing stuff in logfiles, then that's
> fine -- if you remove a logfile, that's kind of like removing a data
> file, then :-).
Let me attempt to reiterate my point about removing the logfiles. The
executive summary is that this may indicate some flaw in how BDB or SVN
deals with the log files, which, if resolved, could make SVN a lot more
reliable.
Let's look through the logic of this extraordinary claim:
First, note that when I removed the corrupt logfile, I did NOT lose any
data. This indicates that the data was safely stored in the database
somewhere. Thus, the problem appears to have been that the system crash
broke BDB or the logfile in such a way that BDB *thought* that the log
was still active, when it had really been flushed to some other part of
the database, probably hours before.
Worse, this problem made the database unrecoverable, even by db_recover
-c. Yet my data was *absolutely intact* and readable once I manually
purged the corrupt logfile. (The database itself was toast and couldn't
be written to...)
Now, this appears to suggest a weakness in how BDB and/or SVN deals
with the logging capability, doesn't it? Some piece of metadata about
whether a logfile is active or not gets a bit flipped or whatever, and
all of a sudden the entire database is irreversibly, unrecoverably
broken?
Sure, deleting a log file is a stupid last ditch idiot thing that I
tried in a panic. But the fact that it worked may indicate a flaw in
the logging procedures, and definitely one in the recovery procedures.
So try to forget how idiotic it was, and focus on what this may
indicate about db reliability issues.
Finally, note that this is now at least TWO times that I've been able
to partially fix an "unrecoverable" svn repository by removing
corrupted logfiles. Thus, I don't think this is some random,
unrepeatable fluke thing but possibly an actual issue in BDB or how SVN
and BDB interact.
Zach Pincus
Department of Biochemistry and Program in Biomedical Informatics
Stanford University School of Medicine
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Posted by kf...@collab.net.
Zachary Pincus <zp...@stanford.edu> writes:
> Wait a second... I thought the whole point of using BDB was that it
> was journaled, and that any transaction was thus guaranteed atomic and
> re-playable (if the transaction was a success).
>
> So, (a) how is it that a commit that happened hours before the power
> went down existed *only* in a log file? And (b), is there a way to
> "play back" all of the non-corrupted transactions? That is, if
> transaction N resides only in the (corrupted) log file but everything
> else is properly journaled/whatever, shouldn't it be trivial to
> restore the DB back to state N-1? It seems really unfortunate that if
> a log file gets corrupted, there's no simple way to roll the
> repository back to the last "usable" state, and instead you have to
> rely on questionable database "recovery" steps that apparently don't
> deal super-well deal bungled logfiles.
You're getting into BDB implementation details. BDB is allowed to
store data anywhere it wants, as long as it doesn't lose it. If the
way it guarantees things is by storing stuff in logfiles, then that's
fine -- if you remove a logfile, that's kind of like removing a data
file, then :-).
> Further, as I stated, by deleting the logfile, I was able to restore
> (read-only) functionality to the repository -- *all the way up to the
> latest commit*. So it appears that the real problem wasn't that the
> last commit hadn't been flushed from the log to the database, but that
> BDB had somehow forgotten that it had already flushed that and thought
> that the logfile was still somehow active. Is this a separate
> vulnerability in BDB?
>
> Presumably I am missing some subtleties of how the DB functions. As
> such, I'm not trying to be antagonistic with these questions, but just
> trying to reconcile what I know (mostly from the SVN docs, which make
> strong claims about why BDB is great) with what you're telling me
> now. A deeper understanding of the DB would certainly help me get
> things sorted out!
The BDB code and docs filtered through me would be a poor informant
indeed, so I recommend seeing them instead.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Posted by Zachary Pincus <zp...@stanford.edu>.
Wait a second... I thought the whole point of using BDB was that it was
journaled, and that any transaction was thus guaranteed atomic and
re-playable (if the transaction was a success).
So, (a) how is it that a commit that happened hours before the power
went down existed *only* in a log file? And (b), is there a way to
"play back" all of the non-corrupted transactions? That is, if
transaction N resides only in the (corrupted) log file but everything
else is properly journaled/whatever, shouldn't it be trivial to restore
the DB back to state N-1? It seems really unfortunate that if a log
file gets corrupted, there's no simple way to roll the repository back
to the last "usable" state, and instead you have to rely on
questionable database "recovery" steps that apparently don't deal
super-well deal bungled logfiles.
Further, as I stated, by deleting the logfile, I was able to restore
(read-only) functionality to the repository -- *all the way up to the
latest commit*. So it appears that the real problem wasn't that the
last commit hadn't been flushed from the log to the database, but that
BDB had somehow forgotten that it had already flushed that and thought
that the logfile was still somehow active. Is this a separate
vulnerability in BDB?
Presumably I am missing some subtleties of how the DB functions. As
such, I'm not trying to be antagonistic with these questions, but just
trying to reconcile what I know (mostly from the SVN docs, which make
strong claims about why BDB is great) with what you're telling me now.
A deeper understanding of the DB would certainly help me get things
sorted out!
Thanks for your time,
Zach Pincus
On Jul 1, 2005, at 11:17 AM, kfogel@collab.net wrote:
> Zachary Pincus <zp...@stanford.edu> writes:
>> Thanks for putting up this information! Unfortunately, I was never
>> able to get my original repository fully-recovered. Though, as I said,
>> through some miracle I did manage to get it to a state where I could
>> perform a dump, by playing stupid games with the log files.
>>
>> Since power had gone down well *after* the last commit to SVN, the
>> only thing that seemed to have gotten corrupt was the log files
>> themselves, and not the db; and it seems (in the few times I've had
>> this type of problem) that BDB is very sensitive to corrupt log files
>> and has difficulty recovering from them.
>
> Well, until a checkpoint happens (i.e., data is sync'd from log file
> to database file), the logfiles hold the only copy of actual data. So
> BDB's sensitivity to logfile corruption is understandable! :-)
>
> -Karl
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Posted by Jake Robb <ja...@mac.com>.
When do checkpoints happen? Can they be triggered?
-Jake
-----Original Message-----
From: kfogel@newton.ch.collab.net [mailto:kfogel@newton.ch.collab.net] On
Behalf Of kfogel@collab.net
Sent: Friday, July 01, 2005 2:17 PM
To: Zachary Pincus
Cc: users@subversion.tigris.org
Subject: Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Zachary Pincus <zp...@stanford.edu> writes:
> Thanks for putting up this information! Unfortunately, I was never
> able to get my original repository fully-recovered. Though, as I said,
> through some miracle I did manage to get it to a state where I could
> perform a dump, by playing stupid games with the log files.
>
> Since power had gone down well *after* the last commit to SVN, the
> only thing that seemed to have gotten corrupt was the log files
> themselves, and not the db; and it seems (in the few times I've had
> this type of problem) that BDB is very sensitive to corrupt log files
> and has difficulty recovering from them.
Well, until a checkpoint happens (i.e., data is sync'd from log file
to database file), the logfiles hold the only copy of actual data. So
BDB's sensitivity to logfile corruption is understandable! :-)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Posted by kf...@collab.net.
Zachary Pincus <zp...@stanford.edu> writes:
> Thanks for putting up this information! Unfortunately, I was never
> able to get my original repository fully-recovered. Though, as I said,
> through some miracle I did manage to get it to a state where I could
> perform a dump, by playing stupid games with the log files.
>
> Since power had gone down well *after* the last commit to SVN, the
> only thing that seemed to have gotten corrupt was the log files
> themselves, and not the db; and it seems (in the few times I've had
> this type of problem) that BDB is very sensitive to corrupt log files
> and has difficulty recovering from them.
Well, until a checkpoint happens (i.e., data is sync'd from log file
to database file), the logfiles hold the only copy of actual data. So
BDB's sensitivity to logfile corruption is understandable! :-)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repeated "unrecoverable" BDB problems (ver 1.1.3)
Posted by Zachary Pincus <zp...@stanford.edu>.
Karl,
Thanks for putting up this information! Unfortunately, I was never able
to get my original repository fully-recovered. Though, as I said,
through some miracle I did manage to get it to a state where I could
perform a dump, by playing stupid games with the log files.
Since power had gone down well *after* the last commit to SVN, the only
thing that seemed to have gotten corrupt was the log files themselves,
and not the db; and it seems (in the few times I've had this type of
problem) that BDB is very sensitive to corrupt log files and has
difficulty recovering from them.
Zach
On Jul 1, 2005, at 7:07 AM, kfogel@collab.net wrote:
> kfogel@collab.net writes:
>> Instead, you should try using Berkeley's 'db_recover' utility first,
>> passing it the '-c' option, meaning "perform catastrophic recovery".
>> (See http://www.sleepycat.com/docs/utility/db_recover.html.)
>>
>> Make sure nothing else is accessing the repository when you do it.
>>
>> I'm surprise to find that there is no way to tell 'svnadmin recover'
>> to do a catastrophic recovery, and that we don't seem to have a FAQ
>> item on this. I'll try to do something about the latter, at least.
>
> Okay, we have information about this in our FAQ now, see
>
> http://subversion.tigris.org/faq.html#wedged-repos
>
> (or rather, see it five minutes from now, when the live site gets the
> updates I just committed :-) ).
>
> Let us know if db_recover helped you at all.
>
> -Karl
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org