incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: recovering data from an unfinished compaction db
Date Mon, 24 Sep 2012 17:08:06 GMT

On 24 September 2012 18:02, Robert Newson <> wrote:
> 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 <> wrote:
>> On Mon, Sep 24, 2012 at 11:42 AM, Rudi Benkovič <> wrote:
>>> On Mon, Sep 24, 2012 at 6:00 PM, Paul Davis <>
>>>> 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.

View raw message