couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: couch behavior for san snapshots
Date Mon, 19 Oct 2009 19:42:58 GMT
On Mon, Oct 19, 2009 at 12:37 PM, Alex P <apedenko@kolosy.com> wrote:
> i'll take a peek tonight, but it just doesn't sound like corruption. the db
> is visible, readable, writable, just has an update sequence of 0, 0 docs and
> a db size (as reported by futon) of 4.0kb.
>
> is db size computed off the file size, or based on actual contents? because
> if it's the file size, it really doesn't sound like corruption...
>

I think it just reports the file size. So if the SAN-restore only
brought back 4kb, then there's something to investigate.

It could be that the SAN inserted a few bytes randomly in the file, so
CouchDB couldn't find a btree root at the position indicated by the
header.

Which version of CouchDB are you using?

I think it's worth diffing the before-restore and after-restore files.
If the after-restore is really only 4kb then of course CouchDB isn't
seeing docs in it.




> (fwiw this is a separate, yet similar issue from the one i had earlier with
> data disappearing from a live system)
>
> On Mon, Oct 19, 2009 at 2:35 PM, Alex P <apedenko@kolosy.com> wrote:
>
>> cdb catalogs databases purely on file name and presence in the appropriate
>> directory, right? so if i copy db1 to db1_copy, i should see db1_copy show
>> up in futon?
>>
>>
>> On Mon, Oct 19, 2009 at 2:23 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:
>>
>>> On Mon, Oct 19, 2009 at 3:18 PM, Alex P <apedenko@kolosy.com> wrote:
>>> > hello,
>>> >
>>> > we ran into an issue this weekend where taking a SAN (amazon ebs)
>>> snapshot
>>> > of a couchdb mount somehow brought over only part of the data.
>>> specifically,
>>> > there were two small dbs (call them db1 and db2) on the couch instance,
>>> each
>>> > with several hundred documents. taking the snapshot and bringing it up
>>> again
>>> > showed both databases, but one had 0 documents and an update sequence of
>>> 0.
>>> > the instance the snapshot was taken from still has both databases
>>> showing
>>> > with several hundred databases. we repeated this process several times,
>>> with
>>> > the same effect, on the same db.
>>> >
>>> > any thoughts would be much appreciated, as we are about to go live, and
>>> not
>>> > being able to do a backup of our db is ... disturbing.
>>> >
>>> > thanks,
>>> > alex.
>>> >
>>>
>>> Alex,
>>>
>>> That's most odd. What happens if you try and cp the database file to a
>>> new name? Something like:
>>>
>>> $ cp /usr/local/var/lib/couchdb/db1.couch
>>> /usr/local/var/lib/couchdb/db3.couch
>>>
>>> Another thing to try would be:
>>>
>>> $ curl -X POST http://127.0.0.1:5984/db1/_ensure_full_commit
>>>
>>> And then try to snapshot or copy again. I highly doubt that POST would
>>> affect anything, but it might be worth a shot.
>>>
>>> Paul Davis
>>>
>>
>>
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message