You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Vladimir Ralev <vl...@gmail.com> on 2019/03/11 14:51:59 UTC
r and w parameters in couch2.x
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
Re: r and w parameters in couch2.x
Posted by Robert Newson <rn...@apache.org>.
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
rnewson@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 <vl...@gmail.com> wrote:
> >
> > OK, I see. Thank you.
> >
> > On Mon, Mar 11, 2019 at 8:48 PM Robert Newson <rn...@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
> >> rnewson@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 <rn...@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
> >>>> rnewson@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/
>
>
Re: r and w parameters in couch2.x
Posted by Jan Lehnardt <ja...@apache.org>.
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 <vl...@gmail.com> wrote:
>
> OK, I see. Thank you.
>
> On Mon, Mar 11, 2019 at 8:48 PM Robert Newson <rn...@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
>> rnewson@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 <rn...@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
>>>> rnewson@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/
Re: r and w parameters in couch2.x
Posted by Vladimir Ralev <vl...@gmail.com>.
OK, I see. Thank you.
On Mon, Mar 11, 2019 at 8:48 PM Robert Newson <rn...@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
> rnewson@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 <rn...@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
> > > rnewson@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
> > > >
> > >
> >
>
Re: r and w parameters in couch2.x
Posted by Robert Newson <rn...@apache.org>.
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
rnewson@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 <rn...@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
> > rnewson@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
> > >
> >
>
Re: r and w parameters in couch2.x
Posted by Vladimir Ralev <vl...@gmail.com>.
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 <rn...@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
> rnewson@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
> >
>
Re: r and w parameters in couch2.x
Posted by Robert Newson <rn...@apache.org>.
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
rnewson@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
>