?????? secondary index creation causes C* oom

Thanks Kurt. -- -- ??: "kurt";; : 2018??1??11??(??) 11:46 ??: "User"; : Re: secondary index creation causes C* oom 1.not sure if secondary index creation is the same as

Re: secondary index creation causes C* oom

> 1.not sure if secondary index creation is the same as index rebuild > Fairly sure they are the same. > 2.we noticed that the memory table flush looks still working,not the same > as CASSANDRA-12796 mentioned,but the compactionExecutor pending is > increasing. > Do you by chance have

Re: sstabledump tries to delete a file

Yes it should be read only, open a jira please. It does look like if the fp changed it would rebuild or if your missing. When it builds the table metadata from the sstable it can just set the properties to match that of the sstable to prevent this. Chris On Wed, Jan 10, 2018 at 4:16 AM,

Re: [announce] Release of Cassandra Prometheus metrics exporter

Hello Romain, This is an amazing information! I truly believe that monitoring is still a weak point for many people, in many companies, even though it is quite easy to share between us. I mean all the cluster have to be mostly monitored the same way (+ some specificities). Because of this, I

Re: Meltdown/Spectre Linux patch - Performance impact on Cassandra?

For what it’s worth, we (TLP) just posted some results comparing pre and post meltdown statistics: http://thelastpickle.com/blog/2018/01/10/meltdown-impact-on-latency.html > On Jan 10, 2018, at 1:57 AM, Steinmaurer,

Error while performing repair: "Did not get positive replies from all endpoints"

​I have a 10 node C* cluster with 4-5 keyspaces​. I tried to perform nodetool repair one by one for each keyspace. For some keyspaces the repair passed but for some it gave this error: ​ I am not able to figure out what is causing this issue.The replica nodes are up and I am able to ping them from

Re: Question upon gracefully restarting c* node(s)

Shutdown (drain, rather) does all of those things, but it’s not very patient - it doesn’t sleep (and there’s no setup time like reconnecting for every invocation of nodetool) so things shutdown quickly in rapid succession, which may have client-visible impact. -- Jeff Jirsa > On Jan 10,

Re: Calling StorageService.loadNewSSTables function results in deadlock with compaction background task.

Can you open a JIRA with this info? -- Jeff Jirsa > On Jan 10, 2018, at 2:34 AM, Desimpel, Ignace > wrote: > > Tested on version 2.2.11 (but seems like trunck 3.x is still the same for the > related code path), using nodetool refresh for restoring a snapshot >

[announce] Release of Cassandra Prometheus metrics exporter

Hello C*, A little mail to announce that we released today our internal tool at Criteo to monitor Cassandra nodes with Prometheus[1]. https://github.com/criteo/cassandra_exporter The application is production ready as we use it internally to monitor our > 100 Cassandra nodes. I hope it can be

Re: C* Logs to Kibana

Wondering what is the purpose - is it to get some insight into the cluster? Besides the logs themselves, another approach that many and I have taken is to pull the JMX metrics from Cassandra and push them to an appropriate metrics/timeseries system. Here's one approach of getting JMX metrics

Re: Too many tombstones using TTL

"The question is why Cassandra creates a tombstone for every column instead of single tombstone per row?" --> Simply because technically it is possible to set different TTL value on each column of a CQL row On Wed, Jan 10, 2018 at 2:59 PM, Python_Max wrote: > Hello, C*

Re: Deleted data comes back on node decommission

Thank you all for your help. I was able to get rid of zombies (at least end users not reporting that anymore) using nodetool cleanup. And old SSTables were indeed unable to merge with each other because of repairedAt > 0, so cassandra stop + sstablerepairedset + cassandra start in rolling manner

Re: Question upon gracefully restarting c* node(s)

Just curious - aside from the "sleep", is this all not part of the shutdown command? Is this an "opportunity" to improve C*? Having worked with RDBMSes, Hadoop and HBase, stopping communication, flushing memcache (HBase), and relinquishing ownership of data (HBase) is all part of the shutdown

Too many tombstones using TTL

Hello, C* users and experts. I have (one more) question about tombstones. Consider the following example: cqlsh> create keyspace test_ttl with replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; use test_ttl; cqlsh> create table items(a text, b text, c1 text, c2 text, c3 text,

Re: Unsubscribe

Hello, To unsubscribe send an email to user-unsubscr...@cassandra.apache.org, sending it to Cassandra user list spams people instead :). C*heers, Alain 2017-12-19 19:04 GMT+00:00 Gerardo R. Blanco : > >

Re: unsubscribe

Hello, To unsubscribe send an email to user-unsubscr...@cassandra.apache.org, sending it to Cassandra user list spams people instead :). C*heers, Alain 2017-12-19 17:27 GMT+00:00 raghavendra vutti : > >

Re: [EXTERNAL] Cassandra cluster add new node slowly

> > I suspect the compactionthroughput has an influence on the new node > joining. The command nodetool | getcompactionthroughput says 'Current > compaction throughput: 32 MB/s’. I would say this guess is true, but maybe not the way you think: the more disk IO you use for compactions, the

Re: Question upon gracefully restarting c* node(s)

I agree with comments above. Cassandra is robust, and we are just talking about optimising the process. Nothing mandatory. Going to an extreme I would say you can pull and plug back the node power cable and call it a restart, It should not harm if your cluster is properly tuned. Yet optimisation

Re: Rebuild to a new DC fails every time

Hello Martin. Did you solve your issue? I would say that this exception could be due to 'streaming_socket_timeout_in_ms' indeed. Make sure you have a large value enough or indeed upgrade to a newer version implementing the keep alive is indeed an interesting thing to try. The thing is if you are

Re: how to check C* partition size

Hello, You can also graph metrics using Datadog / Grafana or any other monitoring tool. Look at the max / mean partition size I would say, see: http://cassandra.apache.org/doc/latest/operating/metrics.html#table-metrics. There is also a metric called 'EstimatedPartitionSizeHistogram' yet it is a

Calling StorageService.loadNewSSTables function results in deadlock with compaction background task.

Tested on version 2.2.11 (but seems like trunck 3.x is still the same for the related code path), using nodetool refresh for restoring a snapshot I guess the Cassandra committers can do something with this . Calling StorageService.loadNewSSTables function results in deadlock with compaction

Re: C* Logs to Kibana

Hi, I believe you can use Logstash to parse C* logs, using some grok pattern like those : https://gist.github.com/ibspoof/917a888adb08a819eab7163b97e018cb so that you gain some nice insight of what your cluster is really doing ! It feel more "native" than to add some jar in C* lib in order to

sstabledump tries to delete a file

Hello all. I have an error when trying to dump SSTable (Cassandra 3.11.1): $ sstabledump mc-56801-big-Data.db Exception in thread "main" FSWriteError in /var/lib/cassandra/data///mc-56801-big-Summary.db at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:142)

C* Logs to Kibana

Hi All, I want to push the Cassandra logs (version 3.x) to Kibana. Is there a way to configure the Cassandra logs to be in json format? If modifying the logs to json is not an option, I came across this blog post from about a year ago regarding that matter:

RE: Meltdown/Spectre Linux patch - Performance impact on Cassandra?

m4.xlarge do have PCID to my knowledge, but possibly we need a rather new kernel 4.14. But I fail to see how this could help anyway, cause this looks highly Amazon Hypervisor patch related and we do not have the production instances patched at OS/VM level (yet). Thomas From: Dor Laor