Re: Consistency Level vs. Retry Policy when no local nodes are available

I think the general assumption is that DC failover happens at the client app level rather than the Cassandra level due to the potentially very significant difference in request latency if you move from a app-local DC to a remote DC. The preferred pattern for most people is that the app fails in a

Re: Very odd & inconsistent results from SASI query

As secondary indexes are stored individually on each node what you're suggesting sounds exactly like a consistency issue. the fact that you read 0 cells on one query implies the node that got the query did not have any data for the row. The reason you would sometimes see different behaviours is

question on maximum disk seeks

I'm trying to understand the maximum number of disk seeks required in a read operation in Cassandra. I looked at several online articles including this one: https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutReads.html As per my understanding, two disk seeks are required in the

Re: Consistency Level vs. Retry Policy when no local nodes are available

Specifically, this puts us in an awkward position because LOCAL_QUORUM is desirable so that we don't have unnecessary cross-DC traffic from the client by default, but we can't use it because it will cause complete failure if the local DC goes down. And we can't use QUORUM because it would fail

Re: Very odd & inconsistent results from SASI query

Apologies for the stream-of-consciousness replies, but are the dropped message stats output by tpstats an accumulation since the node came up, or are there processes which clear and/or time-out the info? On Mon, Mar 20, 2017 at 3:18 PM, Voytek Jarnot wrote: > No dropped

Re: repair performance

good point! i did not (so far) i will do that - especially because i often see all compaction threads being used during repair (according to compactionstats). thank you also for your link recommendations. i will go through them. On Sat, 2017-03-18 at 16:54 +, Thakrar, Jayesh wrote: You

Re: Very odd & inconsistent results from SASI query

Appreciate the reply, Kurt. I sanitized it out of the traces, but all trace outputs listed the same node for all three queries (1 working, 2 not working). Read repair chance set to 0.0 as recommended when using TWCS. I'll check tpstats - in this environment, load is not an issue, but network

Re: Purge data from repair_history table?

default_time_to_live is a convenience parameter that automatically applies a TTL to incoming data. Every field that's inserted can have a separate TTL. The TL;DR of all this is that changing default_time_to_live doesn't change any existing data retroactively. You'd have to truncate the table if

Re: Very odd & inconsistent results from SASI query

No dropped messages in tpstats on any of the nodes. On Mon, Mar 20, 2017 at 3:11 PM, Voytek Jarnot wrote: > Appreciate the reply, Kurt. > > I sanitized it out of the traces, but all trace outputs listed the same > node for all three queries (1 working, 2 not working).

Scrubbing corrupted SStable.

I am trying to scrub a Column family using nodetool scrub, is it going to create snapshots for sstables which are corrupted or for all the sstables it is going to scrub ?? and to remove snapshots created does running nodetool clearsnapshot is enough or do i need to manually delete pre-scrub data

AW: question on maximum disk seeks

Hi, youre right – one seek with hit in the partition key cache and two if not. Thats the theory – but two thinge to mention: First, you need two seeks per sstable not per entire read. So if you data is spread over multiple sstables on disk you obviously need more then two reads. Think of

Re: How can I scale my read rate?

On 20/03/2017 22:05, Michael Wojcikiewicz wrote: Not sure if someone has suggested this, but I believe it's not sufficient to simply add nodes to a cluster to increase read performance: you also need to alter the ReplicationFactor of the keyspace to a larger value as you increase your cluster

Re: question on maximum disk seeks

On 2017-03-20 13:17 (-0700), preetika tyagi wrote: > I'm trying to understand the maximum number of disk seeks required in a > read operation in Cassandra. I looked at several online articles including > this one: >

Re: Purge data from repair_history table?

Hi, On Fri, Mar 17, 2017 at 2:22 PM Paulo Motta wrote: > It's safe to truncate this table since it's just used to inspect repairs > for troubleshooting. You may also set a default TTL to avoid it from > growing unbounded (this is going to be done by default on

Re: How can I scale my read rate?

On 20/03/2017 02:35, S G wrote: 2) https://docs.datastax.com/en/developer/java-driver/3.1/manual/statements/prepared/ tells me to avoid preparing select queries if I expect a change of columns in my table down the road. The problem is also related to select * which is considered bad practice

spikes in blocked native transport requests

we have a datacenter which is currently used exlusively for spark batch jobs. in case batch jobs are running against that environment we can see very high peaks in blocked native transport requests (up to 10k / minute). i am concerned because i guess that will slow other queries (in case other

Re: spikes in blocked native transport requests

Did you check STW GCs? You can do that with 'nodetool gcstats', by looking at the gc.log or observing GC related JMX metrics. 2017-03-20 8:52 GMT+01:00 Roland Otta : > we have a datacenter which is currently used exlusively for spark batch > jobs. > > in case batch jobs

Re: repair performance

I would zero in on network throughput, especially interrack trunks sent from my mobile Daemeon Reiydelle skype daemeon.c.m.reiydelle USA 415.501.0198 On Mar 17, 2017 2:07 PM, "Roland Otta" wrote: > hello, > > we are quite inexperienced with cassandra at the moment