Re: [jira] [Commented] (CASSANDRA-17759) Altering / creating of a keyspace on insufficient number of replicas should filter out gosspping only members

[emmanuel warreng <em...@gmail.com>]

Unsubscribe

On Wed, Jul 20, 2022, 00:19 Stefan Miklosovic (Jira) <ji...@apache.org>
wrote:

>
>     [
> https://issues.apache.org/jira/browse/CASSANDRA-17759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17568760#comment-17568760
> ]
>
> Stefan Miklosovic commented on CASSANDRA-17759:
> -----------------------------------------------
>
> Thanks [~brandon.williams] for the review, I was looking into it, trying
> to understand what you meant but I am not sure I got it. However, what I
> did is that I noticed that there is no need to depend on Gossipper, one
> dependency less ... There is a method "isMember" directly on TokenMetaData
> I am using in the new method.  That way Gossiper uses TokenMetadata but not
> other way around.
>
> > Altering / creating of a keyspace on insufficient number of replicas
> should filter out gosspping only members
> >
> -------------------------------------------------------------------------------------------------------------
> >
> >                 Key: CASSANDRA-17759
> >                 URL:
> https://issues.apache.org/jira/browse/CASSANDRA-17759
> >             Project: Cassandra
> >          Issue Type: New Feature
> >          Components: Legacy/CQL
> >            Reporter: Stefan Miklosovic
> >            Assignee: Stefan Miklosovic
> >            Priority: Normal
> >             Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x
> >
> >
> > When there is a CQL CREATE / ALTER KEYSPACE query executed on a
> gossipping-only member of a cluster (-Dcassandra.join_ring=false) where the
> replication factor is bigger than the number of the nodes, there is
> currently a warning emitted, which is ok, but this number also includes the
> gossipping node itself. This is incorrect as such a node is not part of a
> ring hence it does not hold any data.
> > This is not happening on "data" nodes (members of the ring) as from data
> nodes perspective, gossipping-only members are not visible.
> > We should filter gossipping-only members out of the computation.
> > EDIT:
> > For the sake of the completeness, I leave here the original description
> of this ticket:
> > The original issue for which we refused to do any action:
> > Imagine there is a 5-node cluster where two nodes are gossipping-only
> members (-Dcassandra.join_ring=false) - or in other words, 3 data nodes and
> 2 "coordinator" nodes.
> > Coordinator nodes are capable to speak CQL as well so requests can be
> executed against them. If we create a keyspace against such node, like
> "create keyspace ks1 with replication =
> > {class = "NTS", "dc1": 5}
> > , this query succeeds but if we set CONSISTENCY to ALL in cqlsh and we
> try to insert some data into a table of such keyspace, it will fail -
> because it does not have enough replicas. It has only 3.
> > If this query is executed on data node (a proper member of a ring), this
> should fail too. I think there is a mechanism how to do this, like by
> Guardrails but there is no check which would include gossipping-only
> members into consideration.
> > Ideally, we might introduce a check which would check that the
> replication factor is at most as big as the number of members - irrelevant
> of their current status, they just have to be members of the ring.
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.10#820010)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: commits-help@cassandra.apache.org
>
>