Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CABvT1DGa5bWGbafrsWQkWCospf-afLfhprCSG92S2+pde181tg@mail.gmail.com>
References: 
 <CAFov+BLaetda+GhCK_T4JOwAMONCWcRnDQPknAfjs7MiL044Dg@mail.gmail.com>
	<CABvT1DF09qBkVRBVtrFfUo=MM1cRQB8wuQdUDkbphcg5asUYqA@mail.gmail.com>
	<CAFov+BJuUiaa2-9tpbuehm_ZeXkk2RHsbMHvVEVFj6_AZMPpTw@mail.gmail.com>
	<CABvT1DGa5bWGbafrsWQkWCospf-afLfhprCSG92S2+pde181tg@mail.gmail.com>
Date: Sat, 22 Sep 2012 15:01:35 +0200
Message-ID: 
 <CAFov+BLvvDaeQasyzBcqrf9w2x=pbhivQKtCBcQv4T1G_S-b2w@mail.gmail.com>
Subject: Re: recovering data from an unfinished compaction db
From: =?ISO-8859-2?Q?Rudi_Benkovi=E8?= <rudib@whiletrue.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ok, thanks for the tip. I left it running for about 15 minutes,
however that was on hardware with terribly slow IO (something like
10MB/s). There was no exception (yet?), however Futon or direct HTTP
access to DB didn't produce any output.

I'm copying the 180gig file across the Atlantic to try rebuilding it
on some fast SSD drives. Will let you know how it goes.

Thanks!

--Rudi

On Sat, Sep 22, 2012 at 2:49 PM, Robert Newson <rnewson@apache.org> wrote:
> Yup, CouchDB starts from the end of the file and looks backwards until
> it finds a valid footer, it can take some time if that's a long way
> from the end. It's not so much that CouchDB is skipping over "random
> binary data", it just doesn't have any pointers to that area of the
> file.
>
> How long as couchdb been seeking backward for a footer? When you say
> "doesn't recognize it", are you getting an error message?
>
> B.
>
> On 22 September 2012 13:46, Rudi Benkovi=C4=8D <rudib@whiletrue.com> wrot=
e:
>> CouchDB doesn't recognize it. It's probably corrupted because the
>> partition ran out of free space during compaction itself. Does CouchDB
>> try to find a valid root node by reading the DB file from the tail and
>> skipping over "random" binary data? In that case I might just have to
>> let it run for some time before it finds it.
>>
>> --Rudi
>>
>> On Sat, Sep 22, 2012 at 2:40 PM, Robert Newson <rnewson@apache.org> wrot=
e:
>>> The compacted file is a valid couchdb database, it should not be
>>> "corrupted", simply rename it to .couch.
>>>
>>> Obviously you will have lost any data that didn't make it over to the
>>> .compact file from the original .couch file that you have mistakenly
>>> deleted.
>>>
>>> B.
>>>
>>> On 22 September 2012 10:56, Rudi Benkovi=C4=8D <rudib@whiletrue.com> wr=
ote:
>>>> Hi,
>>>>
>>>> I have a .couch file where compaction hasn't finished its job and
>>>> we've lost the pre-compaction production DB file (an unfortunate
>>>> sysadmin error). Running CouchDB 1.2.0, so the new, corrupted file is
>>>> in disk format version 6, with snappy compression.
>>>>
>>>> I've tried using recover-couchdb
>>>> (https://github.com/jhs/recover-couchdb), but it crashes with the
>>>> message that disk format 6 isn't supported. I've also tried dropping
>>>> in 1.2.0 sources, but that also didn't work.
>>>>
>>>> Anyway, any hints on how to recover the data? 180GB file, lots of atta=
chments.
>>>>
>>>> Many thanks!
>>>>
>>>> --Rudi