You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Carlos Alonso <ca...@cabify.com> on 2017/06/19 16:25:37 UTC
Questions about _membership response meaning
Hi guys.
Moving forward with understanding how CouchDB works when working as a
cluster I've reached the add/remove nodes step and I've seen the following
situations in which I'd like to know what do them mean and if there's
something to take care to avoid errors or unexpected behaviours.
First situation: Having a cluster of 4 nodes, all up and connected (i.e:
they both appear in the all_nodes and cluster_nodes sections of the
_membership endpoint's response), if I ask for any of them to be deleted
(issuing a DELETE against the /_nodes database with its id), it is removed
from the cluster_nodes section and the cluster seems to be working,
possibly because it can still achieve consistency. Is this situation
something considered? What does it exactly mean to be part of all_nodes but
not cluster_nodes?
Second one: Having same setup as above, I bring down a node and then issue
the DELETE request to have it removed both from all_nodes and cluster_nodes
sections. If I then bring the node up again it automatically appears on the
all_nodes section. It only happens if the disk is still available (i.e, all
data it used to have), if I completely replace the disk with a new, empty
one, when I bring it online it does nothing and I have to ask the cluster
to join it by running a PUT request against the /_nodes db. I understand
that some information is persisted into disk that allows it to
automatically join the cluster.
I'd like to have a clearer picture of what it means to appear in the
all_nodes and cluster_nodes and each situation's considerations as I can't
find it documented anywhere. (i.e, if in all_nodes but not in cluster_nodes
it means it cannot...).
Thanks!
--
[image: Cabify - Your private Driver] <http://www.cabify.com/>
*Carlos Alonso*
Data Engineer
Madrid, Spain
carlos.alonso@cabify.com
Prueba gratis con este código
#CARLOSA6319 <https://cabify.com/i/carlosa6319>
[image: Facebook] <http://cbify.com/fb_ES>[image: Twitter]
<http://cbify.com/tw_ES>[image: Instagram] <http://cbify.com/in_ES>[image:
Linkedin] <https://www.linkedin.com/in/mrcalonso>
--
Este mensaje y cualquier archivo adjunto va dirigido exclusivamente a su
destinatario, pudiendo contener información confidencial sometida a secreto
profesional. No está permitida su reproducción o distribución sin la
autorización expresa de Cabify. Si usted no es el destinatario final por
favor elimínelo e infórmenos por esta vía.
This message and any attached file are intended exclusively for the
addressee, and it may be confidential. You are not allowed to copy or
disclose it without Cabify's prior written authorization. If you are not
the intended recipient please delete it from your system and notify us by
e-mail.
Re: Questions about _membership response meaning
Posted by Carlos Alonso <ca...@cabify.com>.
Hi Joan,
Many thanks for your help. It does make sense to think that only nodes that
appear in both lists are actually participating of read/write operations
within the cluster, right?
Nodes appearing only on cluster_nodes are nodes that have been in both
lists but currently are offline and nodes only in all_nodes are reachable
nodes that are not part of the cluster, although, in order to appear there,
it is because at some point they were part of the cluster as well.
Please correct me if I'm wrong.
Regards and thanks again!
On Thu, Jun 29, 2017 at 5:31 PM Joan Touzet <wo...@apache.org> wrote:
> HI Carlos,
>
>
> https://github.com/apache/couchdb/blob/f4c6113808d1809469df9c8be9d2f83ef399f064/src/mem3/src/mem3_httpd.erl#L22-L29
>
> nodes() returns all visible nodes that Erlang is aware of, based on
> the native Erlang clustering functionality. You might have nodes in
> your Erlang distribution cluster that are not CouchDB nodes, such as
> operator consoles or other Erlang OTP applications.
>
> mem3:nodes() returns all nodes participating in the CouchDB cluster.
>
> -Joan
>
> ----- Original Message -----
> From: "Carlos Alonso" <ca...@cabify.com>
> To: "user" <us...@couchdb.apache.org>
> Sent: Thursday, 29 June, 2017 4:48:46 AM
> Subject: Re: Questions about _membership response meaning
>
> Hi guys, just trying to bring this to the top again...
>
> To summarise my questions... What does exactly mean for a server to be part
> of all_nodes and cluster_nodes of the _membership response? Which actions
> are allowed for it on each situation?
>
> Thanks!
>
> On Mon, Jun 19, 2017 at 6:25 PM Carlos Alonso <ca...@cabify.com>
> wrote:
>
> > Hi guys.
> >
> > Moving forward with understanding how CouchDB works when working as a
> > cluster I've reached the add/remove nodes step and I've seen the
> following
> > situations in which I'd like to know what do them mean and if there's
> > something to take care to avoid errors or unexpected behaviours.
> >
> > First situation: Having a cluster of 4 nodes, all up and connected (i.e:
> > they both appear in the all_nodes and cluster_nodes sections of the
> > _membership endpoint's response), if I ask for any of them to be deleted
> > (issuing a DELETE against the /_nodes database with its id), it is
> removed
> > from the cluster_nodes section and the cluster seems to be working,
> > possibly because it can still achieve consistency. Is this situation
> > something considered? What does it exactly mean to be part of all_nodes
> but
> > not cluster_nodes?
> >
> > Second one: Having same setup as above, I bring down a node and then
> issue
> > the DELETE request to have it removed both from all_nodes and
> cluster_nodes
> > sections. If I then bring the node up again it automatically appears on
> the
> > all_nodes section. It only happens if the disk is still available (i.e,
> all
> > data it used to have), if I completely replace the disk with a new, empty
> > one, when I bring it online it does nothing and I have to ask the cluster
> > to join it by running a PUT request against the /_nodes db. I understand
> > that some information is persisted into disk that allows it to
> > automatically join the cluster.
> >
> > I'd like to have a clearer picture of what it means to appear in the
> > all_nodes and cluster_nodes and each situation's considerations as I
> can't
> > find it documented anywhere. (i.e, if in all_nodes but not in
> cluster_nodes
> > it means it cannot...).
> >
> > Thanks!
> > --
> > [image: Cabify - Your private Driver] <http://www.cabify.com/>
> >
> > *Carlos Alonso*
> > Data Engineer
> > Madrid, Spain
> >
> > carlos.alonso@cabify.com
> >
> > Prueba gratis con este código
> > #CARLOSA6319 <https://cabify.com/i/carlosa6319>
> > [image: Facebook] <http://cbify.com/fb_ES>[image: Twitter]
> > <http://cbify.com/tw_ES>[image: Instagram] <http://cbify.com/in_ES
> >[image:
> > Linkedin] <https://www.linkedin.com/in/mrcalonso>
> >
> --
> [image: Cabify - Your private Driver] <http://www.cabify.com/>
>
> *Carlos Alonso*
> Data Engineer
> Madrid, Spain
>
> carlos.alonso@cabify.com
>
> Prueba gratis con este código
> #CARLOSA6319 <https://cabify.com/i/carlosa6319>
> [image: Facebook] <http://cbify.com/fb_ES>[image: Twitter]
> <http://cbify.com/tw_ES>[image: Instagram] <http://cbify.com/in_ES>[image:
> Linkedin] <https://www.linkedin.com/in/mrcalonso>
>
> --
> Este mensaje y cualquier archivo adjunto va dirigido exclusivamente a su
> destinatario, pudiendo contener información confidencial sometida a secreto
> profesional. No está permitida su reproducción o distribución sin la
> autorización expresa de Cabify. Si usted no es el destinatario final por
> favor elimínelo e infórmenos por esta vía.
>
> This message and any attached file are intended exclusively for the
> addressee, and it may be confidential. You are not allowed to copy or
> disclose it without Cabify's prior written authorization. If you are not
> the intended recipient please delete it from your system and notify us by
> e-mail.
>
--
[image: Cabify - Your private Driver] <http://www.cabify.com/>
*Carlos Alonso*
Data Engineer
Madrid, Spain
carlos.alonso@cabify.com
Prueba gratis con este código
#CARLOSA6319 <https://cabify.com/i/carlosa6319>
[image: Facebook] <http://cbify.com/fb_ES>[image: Twitter]
<http://cbify.com/tw_ES>[image: Instagram] <http://cbify.com/in_ES>[image:
Linkedin] <https://www.linkedin.com/in/mrcalonso>
--
Este mensaje y cualquier archivo adjunto va dirigido exclusivamente a su
destinatario, pudiendo contener información confidencial sometida a secreto
profesional. No está permitida su reproducción o distribución sin la
autorización expresa de Cabify. Si usted no es el destinatario final por
favor elimínelo e infórmenos por esta vía.
This message and any attached file are intended exclusively for the
addressee, and it may be confidential. You are not allowed to copy or
disclose it without Cabify's prior written authorization. If you are not
the intended recipient please delete it from your system and notify us by
e-mail.
Re: Questions about _membership response meaning
Posted by Joan Touzet <wo...@apache.org>.
HI Carlos,
https://github.com/apache/couchdb/blob/f4c6113808d1809469df9c8be9d2f83ef399f064/src/mem3/src/mem3_httpd.erl#L22-L29
nodes() returns all visible nodes that Erlang is aware of, based on
the native Erlang clustering functionality. You might have nodes in
your Erlang distribution cluster that are not CouchDB nodes, such as
operator consoles or other Erlang OTP applications.
mem3:nodes() returns all nodes participating in the CouchDB cluster.
-Joan
----- Original Message -----
From: "Carlos Alonso" <ca...@cabify.com>
To: "user" <us...@couchdb.apache.org>
Sent: Thursday, 29 June, 2017 4:48:46 AM
Subject: Re: Questions about _membership response meaning
Hi guys, just trying to bring this to the top again...
To summarise my questions... What does exactly mean for a server to be part
of all_nodes and cluster_nodes of the _membership response? Which actions
are allowed for it on each situation?
Thanks!
On Mon, Jun 19, 2017 at 6:25 PM Carlos Alonso <ca...@cabify.com>
wrote:
> Hi guys.
>
> Moving forward with understanding how CouchDB works when working as a
> cluster I've reached the add/remove nodes step and I've seen the following
> situations in which I'd like to know what do them mean and if there's
> something to take care to avoid errors or unexpected behaviours.
>
> First situation: Having a cluster of 4 nodes, all up and connected (i.e:
> they both appear in the all_nodes and cluster_nodes sections of the
> _membership endpoint's response), if I ask for any of them to be deleted
> (issuing a DELETE against the /_nodes database with its id), it is removed
> from the cluster_nodes section and the cluster seems to be working,
> possibly because it can still achieve consistency. Is this situation
> something considered? What does it exactly mean to be part of all_nodes but
> not cluster_nodes?
>
> Second one: Having same setup as above, I bring down a node and then issue
> the DELETE request to have it removed both from all_nodes and cluster_nodes
> sections. If I then bring the node up again it automatically appears on the
> all_nodes section. It only happens if the disk is still available (i.e, all
> data it used to have), if I completely replace the disk with a new, empty
> one, when I bring it online it does nothing and I have to ask the cluster
> to join it by running a PUT request against the /_nodes db. I understand
> that some information is persisted into disk that allows it to
> automatically join the cluster.
>
> I'd like to have a clearer picture of what it means to appear in the
> all_nodes and cluster_nodes and each situation's considerations as I can't
> find it documented anywhere. (i.e, if in all_nodes but not in cluster_nodes
> it means it cannot...).
>
> Thanks!
> --
> [image: Cabify - Your private Driver] <http://www.cabify.com/>
>
> *Carlos Alonso*
> Data Engineer
> Madrid, Spain
>
> carlos.alonso@cabify.com
>
> Prueba gratis con este código
> #CARLOSA6319 <https://cabify.com/i/carlosa6319>
> [image: Facebook] <http://cbify.com/fb_ES>[image: Twitter]
> <http://cbify.com/tw_ES>[image: Instagram] <http://cbify.com/in_ES>[image:
> Linkedin] <https://www.linkedin.com/in/mrcalonso>
>
--
[image: Cabify - Your private Driver] <http://www.cabify.com/>
*Carlos Alonso*
Data Engineer
Madrid, Spain
carlos.alonso@cabify.com
Prueba gratis con este código
#CARLOSA6319 <https://cabify.com/i/carlosa6319>
[image: Facebook] <http://cbify.com/fb_ES>[image: Twitter]
<http://cbify.com/tw_ES>[image: Instagram] <http://cbify.com/in_ES>[image:
Linkedin] <https://www.linkedin.com/in/mrcalonso>
--
Este mensaje y cualquier archivo adjunto va dirigido exclusivamente a su
destinatario, pudiendo contener información confidencial sometida a secreto
profesional. No está permitida su reproducción o distribución sin la
autorización expresa de Cabify. Si usted no es el destinatario final por
favor elimínelo e infórmenos por esta vía.
This message and any attached file are intended exclusively for the
addressee, and it may be confidential. You are not allowed to copy or
disclose it without Cabify's prior written authorization. If you are not
the intended recipient please delete it from your system and notify us by
e-mail.
Re: Questions about _membership response meaning
Posted by Carlos Alonso <ca...@cabify.com>.
Hi guys, just trying to bring this to the top again...
To summarise my questions... What does exactly mean for a server to be part
of all_nodes and cluster_nodes of the _membership response? Which actions
are allowed for it on each situation?
Thanks!
On Mon, Jun 19, 2017 at 6:25 PM Carlos Alonso <ca...@cabify.com>
wrote:
> Hi guys.
>
> Moving forward with understanding how CouchDB works when working as a
> cluster I've reached the add/remove nodes step and I've seen the following
> situations in which I'd like to know what do them mean and if there's
> something to take care to avoid errors or unexpected behaviours.
>
> First situation: Having a cluster of 4 nodes, all up and connected (i.e:
> they both appear in the all_nodes and cluster_nodes sections of the
> _membership endpoint's response), if I ask for any of them to be deleted
> (issuing a DELETE against the /_nodes database with its id), it is removed
> from the cluster_nodes section and the cluster seems to be working,
> possibly because it can still achieve consistency. Is this situation
> something considered? What does it exactly mean to be part of all_nodes but
> not cluster_nodes?
>
> Second one: Having same setup as above, I bring down a node and then issue
> the DELETE request to have it removed both from all_nodes and cluster_nodes
> sections. If I then bring the node up again it automatically appears on the
> all_nodes section. It only happens if the disk is still available (i.e, all
> data it used to have), if I completely replace the disk with a new, empty
> one, when I bring it online it does nothing and I have to ask the cluster
> to join it by running a PUT request against the /_nodes db. I understand
> that some information is persisted into disk that allows it to
> automatically join the cluster.
>
> I'd like to have a clearer picture of what it means to appear in the
> all_nodes and cluster_nodes and each situation's considerations as I can't
> find it documented anywhere. (i.e, if in all_nodes but not in cluster_nodes
> it means it cannot...).
>
> Thanks!
> --
> [image: Cabify - Your private Driver] <http://www.cabify.com/>
>
> *Carlos Alonso*
> Data Engineer
> Madrid, Spain
>
> carlos.alonso@cabify.com
>
> Prueba gratis con este código
> #CARLOSA6319 <https://cabify.com/i/carlosa6319>
> [image: Facebook] <http://cbify.com/fb_ES>[image: Twitter]
> <http://cbify.com/tw_ES>[image: Instagram] <http://cbify.com/in_ES>[image:
> Linkedin] <https://www.linkedin.com/in/mrcalonso>
>
--
[image: Cabify - Your private Driver] <http://www.cabify.com/>
*Carlos Alonso*
Data Engineer
Madrid, Spain
carlos.alonso@cabify.com
Prueba gratis con este código
#CARLOSA6319 <https://cabify.com/i/carlosa6319>
[image: Facebook] <http://cbify.com/fb_ES>[image: Twitter]
<http://cbify.com/tw_ES>[image: Instagram] <http://cbify.com/in_ES>[image:
Linkedin] <https://www.linkedin.com/in/mrcalonso>
--
Este mensaje y cualquier archivo adjunto va dirigido exclusivamente a su
destinatario, pudiendo contener información confidencial sometida a secreto
profesional. No está permitida su reproducción o distribución sin la
autorización expresa de Cabify. Si usted no es el destinatario final por
favor elimínelo e infórmenos por esta vía.
This message and any attached file are intended exclusively for the
addressee, and it may be confidential. You are not allowed to copy or
disclose it without Cabify's prior written authorization. If you are not
the intended recipient please delete it from your system and notify us by
e-mail.