[ https://issues.apache.org/jira/browse/CASSANDRA-17759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570934#comment-17570934 ]
Brandon Williams commented on CASSANDRA-17759: ---------------------------------------------- Everything looks fine, +1. I think it's best that we follow the ratified process as much as possible, since another pair of eyes is never a bad idea (if you can get them!) and, should something get broken, it's better to have a partner to help shoulder the blame. :) > 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.14, 4.0.6, 4.1-beta, 4.2 > > > 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