couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: _revs_limit_
Date Mon, 12 Apr 2010 12:52:29 GMT
On Apr 12, 2010, at 6:02 AM, Fredrik Widlund wrote:

> Hi,
> We're running a bidirectional replicated (two nodes) setup where a database contains
a couple of hundred small documents, where each document is updated with new data every few
> We're having a few problems getting this to work.
> -          _revs_limit in itself does not stop the database from growing. This is by
design as I understand it.
> -          A low _revs_limit (=10 for example) seems to break replication. Typically
only a few documents are updated through the replication to the node that is not directly
written to. The others are not updated.

I'm guessing that the documents are updated, but that the updates are being saved as conflict
revisions.  Spurious conflicts are the price you pay when _revs_limit is lower than the number
of updates that might occur in between replications.  I would have expected the replicated
update to be the winner, but perhaps I'm overlooking something in the deterministic conflict
revision resolution.

You can check for the presence of conflicts by GET /db/docid?conflicts=true, or by creating
a view which emits doc._conflicts if that field exists.  conflicts=true may become the default
GET behavior in the future.

> -          Regularly compacting the database seems to have some performance (as well
as stability) implications, at least in a replicated scenario.

Could you say more about this, especially the stability part?  We may have a reference counting
bug there.  Hopefully its been fixed recently.

> What's the recommended work flow here? We need to keep updating the database 24/7/365
with data, but without the size growing uncontrollably?

I think you're following recommended procedure so far, although a _revs_limit of 10 doesn't
give you much breathing room if the replication is suspended for a bit.  Best,


> Kind regards,
> Fredrik Widlund

View raw message