couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Corrupted database example file
Date Thu, 18 Apr 2013 18:00:11 GMT
Thanks again for the database to debug. After poking at this for
awhile I can't really come up with solid lead on what might have
happened. I can force decompression to succeed by altering the binary
but the decompressed binary that comes out is quite obviously
corrupted in a number of spots which makes me think that the snappy
compressed binary is actually quite messed up. Rather than spend more
time trying to reverse engineer snappy's compression algorithm I'm
gonna wait to see what sort of file system settings you're running

Specifically of interest is if you're running CouchDB over NFS or if
you have disabled fsync in the CouchDB configuration. Either of those
could lead to behavior like this. Obviously given the wide scale usage
of CouchDB and the scarcity of corruption reports the assumption is
that something in your configuration is breaking the contract for
POSIX apis getting data onto disk safely.

And on the off chance, have you got any idea if this disk is going
bad? Or are you getting corruption on multiple machines?

Let us know what you can. Obviously corruption like this is serious
business for us.

On Thu, Apr 18, 2013 at 7:17 AM, Victor Nicollet <> wrote:
> Hello,
> The @CouchDB twitter account thought you might find this information
> helpful.
> My SaaS start-up uses CouchDB as its primary database. Lately, I have been
> having database corruption issues with version 1.2.0 : every few weeks, one
> of our databases becomes corrupted, which has several negative consequences
> (among others) :
>    - Replication of that database fails (it does not even start).
>    - Compaction of that database fails and *freezes* the server.
>    - Several documents in the database become inaccessible through either
>    direct access or through _all_docs.
>  The latest affected database does not contain any information about our
> customers, so I am allowed to release it publicly :
> This database contains 325 irretrievable documents between identifiers
> 2xFEY0pU2Eb and 3Fn6l04G6Oa.
> I hope this helps,
> --
> Victor Nicollet, CTO,

View raw message