Revisions lost on CouchDB 1.2.0

[Luca Morandini]

Folks,

something puzzling happened on the 11th of November last year to one of our
CouchDB databases: all the non-current revisions were deleted (the rev info shows
them as missing). From that moment on, all revisions were kept (we discovered the
missing revisions only yesterday).

The logs show nothing suspicious on that day.

Can someone shed some light ?

Regards,

Luca Morandini
Data Architect - AURIN project
Melbourne eResearch Group
Department of Computing and Information Systems
University of Melbourne
Tel. +61 03 903 58 380
Skype: lmorandini

[Simon Metson]

Did you run compaction?

[Robert Samuel Newson]

As Simon says, this is the normal and expected behavior of CouchDB after database compaction (or replication). CouchDB is not a revision control system, it only keeps the latest versions (including conflicts) of every document (including deleted ones).

B.

[Luca Morandini]

On 31/01/14 19:42, Robert Samuel Newson wrote:
>
> As Simon says, this is the normal and expected behavior of CouchDB after
> database compaction (or replication). CouchDB is not a revision control system,
> it only keeps the latest versions (including conflicts) of every document
> (including deleted ones).

Compaction was indeed run (the sysadmin has no recollection of it, but it is shown
in the logs, my bad I overlooked it).

I interpreted the _revs_limit parameter as the number of revisions to keep
(including their data), or does CouchDB keep metadata only after a compaction ?

Regards,
Luca Morandini

[Adam Kocoloski]

Correct, _revs_limit controls the number of revisions about which metadata is kept. It's relevant for replication -- if more than _revs_limit updates are applied in between replications to a target DB spurious conflicts can be generated.

Compaction only ever preserves the body of the latest revision on each edit branch.

Adam

[Luca Morandini]

On Friday, 31 January 2014, Simon Metson <si...@cloudant.com> wrote:

> Did you run compaction?
>

I have to correct my previous statement: compaction was run (sysadmin has

no recollection of it, but it is shown in the logs, my bad I overlooked it)

Therefore the question is: how come it deleted all non-current revisions
? Isn't the default behaviour the keeping of the latest 1000 revisions ?

Regards,
Luca Morandini


--

[Luca Morandini]

On Friday, 31 January 2014, Simon Metson <si...@cloudant.com> wrote:

> Did you run compaction?
>

No compaction shown in the logs, and, anyway, the max number of revisions
was not altered, hence it should have been 1000, way above the max number
of revisions we had.

I already looked into Jira, and I was not able to find any related issues.

Thanks for your prompt reply,
Luca Morandini


--

[Noah Slater]

Admittedly, the docs are slightly unclear on this:

"Compaction compresses the database file by removing unused sections
created during updates. Old revisions of documents are also removed
from the database though a small amount of meta data is kept for use
in conflict during replication. The number of revisions (default of
1000) can be configured using the _revs_limit URL endpoint, available
since version 0.8-incubating."

Which is it: does _revs_limit limit the revs, or the metadata about
revs. Could do with cleaning up!

Also, we should probably move this info to the docs and get it out of the wiki.

--
Noah Slater
https://twitter.com/nslater

[Noah Slater]

Sorry, taken from: http://wiki.apache.org/couchdb/Compaction