You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Luca Morandini <lm...@ieee.org> on 2014/01/31 09:16:57 UTC

Revisions lost on CouchDB 1.2.0

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

Re: Revisions lost on CouchDB 1.2.0

Posted by Luca Morandini <lu...@gmail.com>.
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


--

Re: Revisions lost on CouchDB 1.2.0

Posted by Noah Slater <ns...@apache.org>.
Sorry, taken from: http://wiki.apache.org/couchdb/Compaction

On 1 February 2014 16:07, Noah Slater <ns...@apache.org> wrote:
> 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.
>
> On 31 January 2014 09:46, Luca Morandini <lu...@gmail.com> wrote:
>> 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
> https://twitter.com/nslater



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

Re: Revisions lost on CouchDB 1.2.0

Posted by Noah Slater <ns...@apache.org>.
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.

On 31 January 2014 09:46, Luca Morandini <lu...@gmail.com> wrote:
> 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
https://twitter.com/nslater

Re: Revisions lost on CouchDB 1.2.0

Posted by Luca Morandini <lu...@gmail.com>.
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


--

Re: Revisions lost on CouchDB 1.2.0

Posted by Simon Metson <si...@cloudant.com>.
Did you run compaction? 


On Friday, 31 January 2014 at 08:16, Luca Morandini wrote:

> 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
> 
>

Re: Revisions lost on CouchDB 1.2.0

Posted by Adam Kocoloski <ko...@apache.org>.
On Jan 31, 2014, at 6:36 PM, Luca Morandini <lm...@ieee.org> wrote:

> 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

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

Re: Revisions lost on CouchDB 1.2.0

Posted by Luca Morandini <lm...@ieee.org>.
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

Re: Revisions lost on CouchDB 1.2.0

Posted by Robert Samuel Newson <rn...@apache.org>.
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.

On 31 Jan 2014, at 08:16, Luca Morandini <lm...@ieee.org> wrote:

> 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
>