Details
-
New Feature
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
None
-
Semantic
-
Normal
-
All
-
None
-
Description
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.