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

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

Ok this is interesting.

I have a 3-nodes cluster out of which 2 nodes are gossipping only members so we 
have 1 data node only.

When I try to execute this on data node, I get:
{code:java}
cqlsh> CREATE KEYSPACE abc WITH replication = {'class': 
'NetworkTopologyStrategy', 'dc1': 3};

Warnings :
Your replication factor 3 for keyspace abc is higher than the number of nodes 1 
for datacenter dc1
{code}

So, this is ok.

However, when I create that keyspace on one of gossipping-only members, I get 
this:
{code:java}
cqlsh> CREATE KEYSPACE abc WITH replication = {'class': 
'NetworkTopologyStrategy', 'dc1': 3};

Warnings :
Your replication factor 3 for keyspace abc is higher than the number of nodes 2 
for datacenter dc1
{code}

Do you see that "2"? It seems like it counts itself as replica but that logic 
executed on the data node properly sees that that there is 1 replica only.

I ll dig deeper whats up. We might filter out that from the map when it is not 
a member (Gossipper#isGossipOnlyMember)

> 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