Thanks Jan, it was useful to clarify what N means here in case the OP would
increase N if they added more nodes.
N=3 is the default, three separate copies of any individual document, even if
you had 100 nodes in your cluster (any given document would be stored on 3 of
those 100 nodes).
B.
--
Robert Samuel Newson
rnew...@apache.org
On Tue, 12 Mar 2019, at 07:25, Jan Lehnardt wrote:
> Specifically, n is the number of copies of your data, not the number of
> nodes in the system. You can tweak read concurrency performance by
> increasing a database’s number of shards (q) and adding more nodes for
> those shards to live on, at the expense of view, all_docs and changes
> requests becoming more expensive.
>
> > On 12. Mar 2019, at 08:08, Vladimir Ralev <vladimir.ra...@gmail.com> wrote:
> >
> > OK, I see. Thank you.
> >
> > On Mon, Mar 11, 2019 at 8:48 PM Robert Newson <rnew...@apache.org> wrote:
> >
> >> Hi,
> >>
> >> Yes, you will have 4 copies of your data, your nodes will be mirrors of
> >> each other in effect.
> >>
> >> R and W only control one thing; the number of replies we wait for before
> >> returning your response. All N requests are made, in parallel, no matter
> >> what setting for R or W you use. You're not saving I/O by changing it, you
> >> are just modifying your latency (lower values of R and W will lower request
> >> latency) and consistency (higher values of R and W will improve
> >> consistency, though nothing delivers strong consistency in CouchDB).
> >>
> >> Your understanding is not quite right, and so there neither are the
> >> inferences made from that base.
> >>
> >> B.
> >>
> >> --
> >> Robert Samuel Newson
> >> rnew...@apache.org
> >>
> >> On Mon, 11 Mar 2019, at 15:25, Vladimir Ralev wrote:
> >>> Ah thanks a lot for the reply.
> >>>
> >>> The idea for n = 4 is both fault tolerance and performance. Since I have
> >>> very few writes, I expect replication IO and view indexing IO to be
> >> minimal
> >>> and I have no issues with temporary inconsistencies and conflicts.
> >>>
> >>> My understanding is that since there are very few writes, the 4 nodes
> >> will
> >>> behave almost like 4 independent single nodes and will be able to serve
> >> the
> >>> read requests independently without having to proxy to cluster peers and
> >>> thus avoiding a great deal of extra network and disk IO.
> >>>
> >>> R=3 to me means 3 times the IO and thus 3 machines will be busy for the
> >>> same read request instead of serving other requests. Which I understand
> >> is
> >>> 3 times less performance from the cluster as a whole.
> >>>
> >>> If my understanding is correct, I imagine this would be a common use-case
> >>> for couch?
> >>>
> >>> On Mon, Mar 11, 2019 at 4:58 PM Robert Newson <rnew...@apache.org>
> >> wrote:
> >>>
> >>>> r and w are no longer configurable from the config file by design. The
> >>>> default is n/2+1 (so 3 in your case) unless you specify r or w as
> >> request
> >>>> parameters.
> >>>>
> >>>> setting n = 4 for a 4 node cluster is very unusual, do you really need
> >> 4
> >>>> full copies of your data?
> >>>>
> >>>> couchdb will also automatically lower both r and w if nodes are
> >> offline.
> >>>>
> >>>> The default of n=3, r=w=2 is appropriate in almost all cases as the
> >> right
> >>>> balance between data safety and availability. Nothing you've said so
> >> far
> >>>> suggests it would be good to deviate from those settings.
> >>>>
> >>>> --
> >>>> Robert Samuel Newson
> >>>> rnew...@apache.org
> >>>>
> >>>> On Mon, 11 Mar 2019, at 14:52, Vladimir Ralev wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> I am looking into running a 4-node couchdb 2.3 with this config in
> >>>>> default.ini and I made sure no other config file override them:
> >>>>> [cluster]
> >>>>> q = 8
> >>>>> n = 4
> >>>>> r = 1
> >>>>> w = 1
> >>>>>
> >>>>> But when i create a test DB and check the settings I get:
> >>>>> curl -s couch01:5984/mytest1234 |jq . .... .... "cluster": { "q": 8,
> >>>> "n": 4,
> >>>>> "w": 3, "r": 3 },
> >>>>>
> >>>>> r and w settings are not respected and seem stuck to be the defaults.
> >>>>>
> >>>>> When I kill 3 of the machine and test reads and writes, they still
> >> work
> >>>>> fine so it doesn't seem like the r and w are actually 3 either. I
> >> checked
> >>>>> if the debug logs printed out the r and w anywhere to confirm what is
> >>>> being
> >>>>> configured or executed but there is nothing.
> >>>>>
> >>>>> It is unclear if r and w are active in this version of couch. I can
> >> see
> >>>>> the
> >>>>> they have been partially removed from the documentation
> >>>>> https://docs.couchdb.org/en/master/cluster/theory.html as opposed to
> >>>>> couchdb 2.0.0 original doc
> >>>>>
> >>>>
> >> https://web.archive.org/web/20160109122310/https://docs.couchdb.org/en/stable/cluster/theory.html
> >>>>>
> >>>>> Additionally curl -s couch01:5984/mytest1234/doc?r=3
> >>>>> still works even if 3 out of the 4 nodes are dead which is
> >> unexpected per
> >>>>> the quorum documentation here
> >>>>> https://docs.couchdb.org/en/master/cluster/sharding.html#quorum
> >>>>>
> >>>>> My specific concern with r and w is that if r is 3 this means 3 times
> >>>> more
> >>>>> network and disk IO since it will have to read 3 times from remote
> >>>>> machines. My use case really doesn't need this and performance will
> >>>> suffer.
> >>>>> This is a little hard to test so I was hopinh someone can shed some
> >> light
> >>>>> on the current situation with r and w in couch 2.3.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>
> >>>
> >>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
>
