Not enough replica available for query at consiste

Question

I have a Cassandra cluster with three nodes, two of which are up. They are all in the same DC. When my Java application goes to write to the cluster, I get an error in my application that seems to be caused by some problem with Cassandra:

Caused by: com.datastax.driver.core.exceptions.UnavailableException: Not enough replica available for query at consistency ONE (1 required but only 0 alive) at com.datastax.driver.core.exceptions.UnavailableException.copy(UnavailableException.java:79)

The part that doesn't make sense is that "1 required but only 0 alive" statement. There are two nodes up, which means that one should be "alive" for replication.

Or am I misunderstanding the error message?

Thanks.

Answer 1

in my case, I got a message 0 available, but cassandra was up and cqlsh worked correctly, the problem was accessing from java: query was for a complete table, and some records were not accesible (all nodes containing them down). From cqlsh, select * from table works, only shows accesible records. So, the solution is to recover down nodes, and maybe to change replication factors with:

 ALTER KEYSPACE ....
nodetool repair -all 

then nodetool status to see changes and cluster structure

Answer 2

You are likely getting this error because the Replication Factor of the keyspace the table you are querying belongs to has a Replication Factor of one, is that correct?

If the partition you are reading / updating does not have enough available replicas (nodes with that data) to meet the consistency level, you will get this error.

If you want to be able to handle more than 1 node being unavailable, what you could do is look into altering your keyspace to set a higher replication factor, preferably three in this case, and then running a nodetool repair on each node to get all of your data on all nodes. With this change, you would be able to survive the loss of 2 nodes to read at a consistency level of one.

This cassandra parameters calculator is a good reference for understanding the considerations of node count, replication factor, and consistency levels.

Answer 3

For me it was that my endpoint_snitch was still set to SimpleSnitch instead of something like GossipingPropertyFileSnitch. This was preventing the multi-DC cluster from connecting properly and manifesting in the error above.

Answer 4

I hit this today because the datacenter field is case sensitive. If your dc is 'somedc01' this isn't going to work:

replication = 
    {
        'class': 'NetworkTopologyStrategy',
        'SOMEDC01': '3'  #  <-- BOOM!
    }
    AND durable_writes = true;

Anyway, it's not that intuitive, hope this helps.