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 <[email protected]> Sent: Tuesday, August 26, 2014 22:09 To: [email protected] 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.
