If the DB was corrupted because the disk became full, shouldn't the DB still be fine but just missing the most recent commits? Or would the a person need to truncate a certain number of bytes off the end of the DB to get it to read properly?
As for JSON file size... I always dump the DB into a GZ file and then my scripts work on it as a GZ'ed file. In my case the JSON is 20gb and the gz file is 3.5gb. Dealing with the file as a gz adds a little more complexity to the script you use to process it, though. On 21 March 2014 15:46, Jens Alfke <[email protected]> wrote: > > On Mar 21, 2014, at 8:43 AM, Alexander Shorin <[email protected]> wrote: > > > we don't have any knowledge about how it was repacked, what > > changes it includes, how it different from original CouchDB 1.2.0 and > > so on and so forth. > > Is that relevant? Nothing's come up in this thread that depends on exact > details of CouchDB internals. Can we focus on the issue at hand, namely > that the OP has a CouchDB that ran out of disk space and corrupted its > database and he'd like to recover the data? > > (IIRC, if there were any source changes from stock 1.2 they were minor, > maybe just around branding. Maybe Jan, Dale, or Filipe remember more about > it?) > > > CouchBase team probably should knows more about their products. > > Couchbase's forums are not going to respond to support requests for a > product that's been discontinued for over two years, from someone who's > (presumably) not a paying customer. > > --Jens
