Python driver concistency problem

Hi, we have three nodes cluster with KS defined as CREATE KEYSPACE someks WITH REPLICATION = { 'class' : 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'some-dc': '3' } AND DURABLE_WRITES = true; next I read with Pyhton (cassandra-driver 3.11) from Cassandra 3.11.3 and get error Er

Re: Python driver concistency problem

Hi Vlad, Maybe the consistency level has been set manually in CQLSH. Did you try checking your consistency level and set it back to normal? (Just a thought, Not sure!!) On Wed, May 22, 2019 at 2:00 PM Vlad wrote: > Hi, > > we have three nodes cluster with KS defined as > > *CREATE KEYSPACE some

Re: Python driver concistency problem

Hi, I do reads in my own Python code, how cqlsh can affect it? On Wednesday, May 22, 2019 12:02 PM, Chakravarthi Manepalli wrote: Hi Vlad, Maybe the consistency level has been set manually in CQLSH. Did you try checking your consistency level and set it back to normal? (Just a thought,

Re: Python driver concistency problem

In a lot of cases, the issue is with the data model. Can you describe the table? Can you provide the query you use to retrieve the data? What's the load on your cluster? Are there lots of tombstones? You can set the consistency level to ONE, just to check if you get responses. Although normally I

Re: Python driver concistency problem

That's the issue - I do not use consistency ALL. I set QUORUM or ONE but it still performs with ALL. On Wednesday, May 22, 2019 12:42 PM, shalom sagges wrote: In a lot of cases, the issue is with the data model. Can you describe the table? Can you provide the query you use to retrieve

Select in allow filtering stalls whole cluster. How to prevent such behavior?

Hello everyone, We have an 8 node C* cluster with large volume of unbalanced data. Usual per-partition selects work somewhat fine, and are processed by limited number of nodes, but if user issues SELECT WHERE IN () ALLOW FILTERING, such command stalls all 8 nodes to halt and unresponsiveness to ex

Re: Select in allow filtering stalls whole cluster. How to prevent such behavior?

Hi Vsevolod, 1) Why such behavior? I thought any given SELECT request is handled by a limited subset of C* nodes and not by all of them, as per connection consistency/table replication settings, in case. When you run a query with allow filtering, Cassandra doesn't know where the data is located, s

Re: A cluster (RF=3) not recovering after two nodes are stopped

Hi, FYI: I created a bug ticket since I think the behavior is just not right. https://issues.apache.org/jira/browse/CASSANDRA-15138 Thanks, Hiro On Mon, May 13, 2019 at 10:58 AM Hiroyuki Yamada wrote: > Hi, > > Should I post a bug ? > It doesn't seem to be an expected behavior, > so I think it

Re: Select in allow filtering stalls whole cluster. How to prevent such behavior?

Hi, "When you run a query with allow filtering, Cassandra doesn't know where the data is located, so it has to go node by node, searching for the requested data." a) Interesting... But only in case you do not provide partitioning key right? (so IN() is for partitioning key?) b) Still does

Necessary consistency level for LWT writes

Hello! I am trying to understand the consistency level (not serial consistency) required for LWTs. Basically what I am trying to understand is that if a consistency level of ONE is enough for a LWT write operation if I do my read with a consistency level of SERIAL? It would seem so based on what