CouchDB Error

[job-isabai]

CouchDB Error

[rnewson]

hi, this looks like data corruption to me. The binary in question is a kp_node but it is somehow truncated or otherwise invalid.

[nickva]

Agree with @rnewson.

<<131,0,104,2,100,0,7,107,112,95...

The first byte 131 looked like a proper initial marker of an uncompressed term.

It's not followed by 80, so it's not compressed

couchdb/src/couch/src/couch_compress.erl

Lines 22 to 26 in c93940a

	-define(SNAPPY_PREFIX, 1).
	% Term prefixes documented at:
	% http://www.erlang.org/doc/apps/erts/erl_ext_dist.html
	-define(TERM_PREFIX, 131).
	-define(COMPRESSED_TERM_PREFIX, 131, 80).

0 following 131 seems odd on first look at https://www.erlang.org/doc/apps/erts/erl_ext_dist.html#introduction. The next 104,2 looks like a proper small tuple

Which is probably what we might expect in a kp node.

But turning a tuple into a binary doesn't show a 0 after 131

> erlang:term_to_binary({a, b}).
<<131,104,2,100,0,1,97,100,0,1,98>>

@job-isabai

What version of CouchDB, Erlang, OS, architecture you're running? Wonder if you backed up, or restored the data at any point. Of if there is any way to reproduce the issue?

[job-isabai]

Hello,
Thanks for the feedback.
I am using CouchDB via Community Health Toolkit (CHT).
Docker image can be found here: https://staging.dev.medicmobile.org/_couch/builds_4/medic:medic:4.5.0/docker-compose/cht-couchdb.yml but I can't tell the version.
This error emerged from a system upgrade which required all views to be indexed before migration to the new version. This takes place automatically in the backend but there was crash a couple of times during migration that resulted me to revert to a backed up version (Whole Image & Files of the VM).
Afterwards, the upgrade was successful, all views were indexed and the system started running on a new version. After a couple of hours this error started popping up, which resulted to CouchDB container restarting unexpectedly. My database size is more than 2GB and growing.

[rnewson]

That image contains CouchDB 3.3.2.

[rnewson]

so I think this is data corruption somehow, you'll need to try earlier backups until something works but we're very curious as to how this might have happened. If you have the details of the storage subsystem (filesystem, disks, any virtualisation between couchdb and the storage device, and any relevant settings on reordering or fsyncing) we'd love to hear them.

[job-isabai]

Actually reverting back to earlier backups might not be an option for me since it has been a month and I might loose the current state of the database. Is there a means of repairing the corrupted data? Can I adjust the configuration to make CouchDB container error tolerant to prevent failure/restart?
Running on Ubuntu VM, docker system where everything is stored on the local disk.

[rnewson]

CouchDB is built as a "crash only" system, meaning that the couchdb process is always ready to be killed, there's no shutdown code, no need to call sync manually, etc. When a document is written, and the 200 OK returned, CouchDB has already done everything it can to persist the data to disk (including fsync() calls). At startup CouchDB will read from the end of each file looking for the latest valid header.

Without knowing how the files were corrupted it is hard to know what to recommend and, unfortunately, there are no tools we publish to repair a corrupted .couch file. At best we might be able to build an erlang script that would attempt to extract the document bodies inside the .couch files, though that would be shorn of a number of details (the doc id being the most significant as it is stored in a different location to the body, the corrupted btree index would be able to find it).

Have you perhaps replicated this database elsewhere recently? that could be another source of backup.