couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: data recovery tool progress
Date Tue, 10 Aug 2010 12:59:39 GMT
On Aug 10, 2010, at 6:27 AM, Jan Lehnardt wrote:

> This looks like we are recovering nodes that don't need recovering because on a healthy
db produced with delayed_commits=true we should not have any orphans at all, so the lost and
found db should be empty.

Yes, that would be ideal.  I think the issue is that "prune_nodes" ends up returning all btree
roots except the latest one.  It doesn't actually grab all the headers and remove root nodes
they point to, it only does this for the latest header.  As a result, I think rnewson's results
make sense.

On Aug 10, 2010, at 4:55 AM, Robert Newson wrote:

> In ran the db_repair code on a healthy database produced with
> delayed_commits=true.
> The source db had 3218 docs. db_repair recovered 3120 and then returned with ok.
> I'm redoing that test, but this indicates we're not finding all roots.

On a healthy DB it should have found zero docs.  It probably found all docs except those which
are accessible only from the latest header.

On Aug 10, 2010, at 4:09 AM, Mikeal Rogers wrote:

> I think I found a bug in the current lost+found repair.
> I've been running it against the testwritesdb and it's in a state that is
> never finishing.

I'll bet it's working ok.  prune_nodes() returns 26000+ roots for that DB, so we need to do
26000+ replications, each of which finds a large number of documents.

The solution is to prune more nodes.

View raw message