couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dirkjan Ochtman (JIRA)" <>
Subject [jira] Commented: (COUCHDB-721) possible data corruption after upgrade & compaction
Date Wed, 31 Mar 2010 16:11:29 GMT


Dirkjan Ochtman commented on COUCHDB-721:

Thanks, I was going to file myself this morning, but then you already had.

I chatted with Damien about this last night, here's what we came up with:

20:21 <damienkatz> okay, the database looks completely correct on my side. must be something
                   you view indexes then.
20:26 <damienkatz> the page-22 document doesn't exist in my pages/list view
20:26 <djc> it does in mine
20:27 <damienkatz> right, it's sounds like it's the index that's wrong.
20:27 <djc> but the return for conflicts=true is the same
20:27 <djc> I'm confused, shouldn't revs_info also show the conflicts?
20:29 <damienkatz> djc: no, it only shows the revs for that edit "branch":
20:29 <damienkatz> each conflict is a different edit branch, that's what makes them
20:29 <damienkatz> so revs_info shows all the previous edits to that particular document
20:30 <djc> okay...
20:31 <djc> still, that would indicate that I have overwritten page-22 at some point
with an empty 
20:31 <damienkatz> yes
20:32 <damienkatz> djc: the conflicts still have data
20:33 <damienkatz> err, no they don't
20:33 <damienkatz> has content:
20:34 <djc> yeah, and that's the one that shows up in my view
20:36 <djc> gtg, bbiab
20:44 <damienkatz> djc: save your view index file for me to download. To fix the inconsistency

                   between the view and the db, delete the index file for it to be rebuilt.
20:48 <djc> right, but then I have to make sure I merge all the conflicts
20:48 <djc> I don't even know how to do that, I think, but I bet there's a wiki page
20:48 <damienkatz> djc: delete the other revs
20:49 <damienkatz> DELETE db/doc?rev=4-4212453249
20:50 <djc> ok
20:58 <damienkatz> djc: also, can you write up a bug report for this?
20:58 <djc> just for the view indexer, right?
20:58 <damienkatz> Right. The bug seems to be that the view index got out of sync with
the databse 
20:59 <djc>
20:59 <djc> it's still weird how that empty revision got there
21:00 <damienkatz> djc: there might still be another bug in couchdb there. or it might
the out of 
                   sync index caused a problem in the app logic?
21:02 <djc> the app doesn't write to these documents
21:02 <djc> I've only done that by hand (albeit through a script)
21:02 <djc> we can't trace a seq to a timestamp, right?
21:02 <djc> I guess maybe I could trawl through the logs
21:03 <djc> but even then it would be in a bulk update

> possible data corruption after upgrade & compaction
> ---------------------------------------------------
>                 Key: COUCHDB-721
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Database Core
>    Affects Versions: 0.11
>            Reporter: Timothy Smith
> Problem report filed on behalf of e-mail, subject "Compaction
issue after upgrade 0.10.1-0.11.0".
> So this morning I went to upgrade one of my servers to 0.11. Installed
> it, fixed up the config files, then restarted CouchDB. It picked up on
> my databases just fine, so everything looked good. I tried some views,
> and it had to re-index all of my ddocs (which I found surprising, but
> okay). After that I went and compacted the database, then the views.
> However, later today I got some exception mails from my web
> application. It appears that something has gotten confused. For
> example, take this document:
> {_id: "page-22", _rev: "2-1835830930", lb: null, content: "blah blah
> yadda", type: "page", _deleted_conflicts: ["4-4212453249",
> "2-1982019940", "2-1964049796", "2-1096626370"]}
> Note all the _deleted_conflicts. However, this is the document
> returned by a view (which emits(, doc))! When I actually request
> this document, I get this:
> {"_id":"page-22","_rev":"4-4212453249"} (it would be helpful to have a
> member _deleted:true, or something, to show that it's not just empty,
> but that something was there before).
> Requesting the 2-1835830930 revision results in the complete document,
> as shown above.
> So, that got me pretty scared, because I thought I lost my document
> (and my site actually started failing)! What would be the best way to
> fix up my database? And do we have any diagnosis on what the cause of
> this is? I'm happy I deployed this on a less-critical site first, and
> wouldn't want to deploy at work unless we figure out what's going on
> here.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message