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