_revs_limit_

[Fredrik Widlund <fr...@qbrick.com>]

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

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.

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

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?

Kind regards,
Fredrik Widlund

Re: _revs_limit_

[Adam Kocoloski <ko...@apache.org>]

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 seconds.
> 
> 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,

Adam

> 
> Kind regards,
> Fredrik Widlund
>