[
https://issues.apache.org/jira/browse/CASSANDRA-17759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17759:
------------------------------------------
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.
was:
When there is CQL CREATE / ALTER KEYSPACE query executed on a gossipping-only
member of a cluster where the replication factor is bigger than the number of
the nodes, there is currently a warning emitted, which is ok, but
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.
> 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: [email protected]
For additional commands, e-mail: [email protected]
