[
https://issues.apache.org/jira/browse/CASSANDRA-17759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570527#comment-17570527
]
Stefan Miklosovic commented on CASSANDRA-17759:
-----------------------------------------------
Ah right, I misread that. Sure, take a look, I think it will be all good
anyway. Sometimes it is unclear to me if we are about to follow the steps so
rigorously or some patches are just too simple to go over all of that. If we
agree on the fact that we go "standard way" absolutely every single time, I am
fine with that, I just have this feeling I am bothering you with trivias.
> 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
