Unsubscribe On Wed, Jul 20, 2022, 00:19 Stefan Miklosovic (Jira) <j...@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-unsubscr...@cassandra.apache.org > For additional commands, e-mail: commits-h...@cassandra.apache.org > >
