[ 
https://issues.apache.org/jira/browse/CASSANDRA-17759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17567924#comment-17567924
 ] 

Stefan Miklosovic commented on CASSANDRA-17759:
-----------------------------------------------

Yes, already checked this with Andres, the check was introduced on 3.11.13, I 
was testing 3.11.10 and I dont remember I saw the warning in 3.11.10. I ll just 
do a test with 3.11.13 and with gossipping-only members and we should see the 
same warning there.  That logic of the check does the computation on the token 
map or whatever and gossipping only node sees the same structure, it just 
happens to be not part of it.

I ll close this when tested.

> Creation of a keyspace with RF equal to all nodes including gossipping-only 
> members should fail
> -----------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-17759
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-17759
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Stefan Miklosovic
>            Priority: Normal
>
> 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]

Reply via email to