incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: recovering data from an unfinished compaction db
Date Mon, 24 Sep 2012 17:02:50 GMT
re: Tim, no, the database headers are written at the end of the file
and a database will therefore contain main database headers over time
(the compactor will not preserve old headers, though). This also
implies (correctly) that truncating a couchdb .couch file will give
you the state of the database at some point in the past.

It used to be true that we overwrote the first 8k of the file with 2
copies of the 4k header, but that's not been the case for a few years
now.

B.

On 24 September 2012 17:47, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> On Mon, Sep 24, 2012 at 11:42 AM, Rudi Benkovič <rudib@whiletrue.com> wrote:
>> On Mon, Sep 24, 2012 at 6:00 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>>> The quickest way to fix this would probably be to go back and update
>>> recover-couchdb to recognize the new disk format. Although that gets
>>> harder now that snappy compression is involved.
>>
>> I've tried upgrading recover-couchdb to 1.2.0 couch codebase, but my
>> total lack of Erlang experience and CouchDB's internal really isn't
>> helping. :) I've contacted the maintainer of that project, hopefully
>> it isn't that big of change. BTW, if anyone else wants to do that, I'm
>> happy to sponsor the work.
>>
>> How hard would it be to just grep the compacted DB, extract data
>> around kv_node headers and decompress Snappy data with an external,
>> non-CouchDB-Erlang program? I'm willing to write the thing in C#, just
>> some basic pointers to the DB structure and what data gets compressed
>> and where the Document IDs and attachments data gets stored.
>>
>> Thanks.
>>
>> --Rudi
>
> I'm not familiar enough with the project to comment. I wouldn't think
> it'd be that hard, but its possible something changed enough to
> increase the difficulty. As to reading the format from C# or some
> other language its not something I would be all that interested in
> trying as the bang/buck ratio isn't all that favorable.

Mime
View raw message