couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjuan, Hector" <hector.sanj...@here.com>
Subject RE: best practices on replication? recommended rev_limit value? network config?
Date Tue, 26 Aug 2014 21:18:58 GMT
Hi,

you got it wrong. There is consistency (eventual consistency). Every node agrees that one
of the leaf revisions is the "active" one and they all show the same result when queried (eventually).
So,

1) Eventual consistency is ensured by Couchdb design. You just have to take care of resolving
conflicts manually (eventually correcting Couchdb assumption on which document version prevails).

2) You don't want low values, because during replication that would mean you are assuming
that your nodes are replicating nicely all the time, without network interruptions or limitations.
If your rev_limit is low and you miss to repilicate a number of revisions higher than the
limit for whatever reason, you'll run into trouble. If you are constantly writing the same
document many times, the rev_limit should be high. If your writes operations and spread around
a large number of documents, then the revision numbers won't grow so quickly so you could
lower it. I'm not sure this will save anything than disk space.

3) I'm not sure about that... and I'd like to hear the answer :)

Hector
________________________________________
From: david rene comba lareu <shadow.of.soul08@gmail.com>
Sent: Tuesday, August 26, 2014 22:09
To: user@couchdb.apache.org
Subject: best practices on replication? recommended rev_limit value? network config?

Hi,

i'm a new user of couchdb. my company is developing a SaaS app that
relies completely on json manifest to work, so couchdb was perfect for
the task. We expect a heavy load (100K users), so the replication is a
very important feature for us and like it was promoted that
replication was easy on couchdb, we finally decided to use it.

Before subscribing to the mailing list, i supposed that master ->
master replication was a good option, removing the failure point of
having only one write master at a time, but i just saw that exist's
"leaf"  revisions where the data is not consistent between masters.

so i have a couple of questions, about this:

1) what is the best setup to assure consistency? write-only masters to
read-only slaves like common node setups? Even that performance is
really important we need to prevail consistency on top of everything.
2) we don't need revs at all, all changes are final. reducing
rev_limit value has a positive impact on performance? if it has, what
is the recommended value?
3) like the wiki said that ssl was not supported correctly by erlang,
we set up an haproxy in the frontend that forward the request to the
couchdb http. like is the first time we work on a DB system with an
http frontend (and not a permanent connection like mysql or redis)
what is the recommended setup in terms of network? (like timeout, keep
alive options etc..). any documentation about this is useful.

Any advice regarding on this is highly appreciated !

Regards.

Mime
View raw message