Old tombstones not being cleaned up

Hi, We are running a small 9 node Cassandra v2.1.17 cluster. The cluster generally runs fine, but we have one table that are causing OOMs because an enormous amount of tombstones. Looking at the data in the table (sstable2json), the first of the tombstones are almost a year old. The table was

Re: Nodes show different number of tokens than initially

> > I don’t know why this is a surprise (maybe because people like to talk > about multiple rings, but the fact that replication strategy is set per > keyspace and that you could use SimpleStrategy in a multiple dc cluster > demonstrates this), but we can chat about that another time This is

Re: Security Updates

Regarding security releases, nothing currently exists to notify users when security related patches are released. At the moment I imagine announcements would only be made in NEWS.txt or on the user mailing list... but only if you're lucky. On 31 January 2018 at 19:18, Michael Shuler

Re: Upgrading sstables not using all available compaction slots on version 2.2

Would you be able to create a JIRA ticket for this? Not sure if this is still a problem in 3.0+ but worth creating a ticket to investigate. It'd be really helpful if you could try and reproduce on 3.0.15 or 3.11.1 to see if it's an issue there as well.​

Re: group by select queries

Seems problematic. Would you be able to create a JIRA ticket with the above information/examples? On 30 January 2018 at 22:41, Modha, Digant wrote: > It was local quorum. There’s no difference with CONSISTENCY ALL. > > > > Consistency level set to LOCAL_QUORUM. >

Re: Not what I‘ve expected Performance

How are you copying? With CQLSH COPY or your own script? If you've got spark already it's quite simple to copy between tables and it should be pretty much as fast as you can get it. (you may even need to throttle). There's some sample code here (albeit it's copying between clusters but easily

Re: TWCS not deleting expired sstables

Well, that shouldn't happen. Seems like it's possibly not looking in the correct location for data directories. Try setting CASSANDRA_INCLUDE= prior to running the script? e.g: CASSANDRA_INCLUDE=/cassandra.in.sh sstableexpiredblockers ae raw_logs_by_user On 30 January 2018 at 15:34, Thakrar,

Re: Nodes show different number of tokens than initially

On Wed, Jan 31, 2018 at 12:08 PM, Oleksandr Shulgin < oleksandr.shul...@zalando.de> wrote: > On 31 Jan 2018 17:18, "Jeff Jirsa" wrote: > > > I don’t know why this is a surprise (maybe because people like to talk > about multiple rings, but the fact that replication strategy is

Re: Cleanup blocking snapshots - Options?

Thanks Thomas. I'll give it a shot myself and see if backporting the patch fixes the problem. If it does I'll create a new ticket for backporting. On 30 January 2018 at 09:22, Steinmaurer, Thomas < thomas.steinmau...@dynatrace.com> wrote: > Hi Kurt, > > > > had another try now, and yes, with

RE: [announce] Release of Cassandra Prometheus metrics exporter

Hi Romain Gérard - Thanks for sharing Cassandra-exporter. Since you're already monitoring tons of Cassandra instances nodes - can you please let us know if you can share Prometheus dashboards/json code along with Cassandra-exporter. Thanks/Asad -Original Message- From: Romain

RE: Slender Cassandra Cluster Project

Thank you Yuri and Michael for the suggestion. Yes, a Terraform version makes sense. Will do. Kenneth Brotman -Original Message- From: Yuri Subach [mailto:ysub...@gmail.com] Sent: Wednesday, January 31, 2018 7:20 AM To: user@cassandra.apache.org Subject: Re: Slender Cassandra Cluster

Re: Nodes show different number of tokens than initially

On 31 Jan 2018 17:18, "Jeff Jirsa" wrote: I don’t know why this is a surprise (maybe because people like to talk about multiple rings, but the fact that replication strategy is set per keyspace and that you could use SimpleStrategy in a multiple dc cluster demonstrates this),

Re: Security Updates

I should also mention the dev@ mailing list - this is where the [VOTE] emails are sent and you'd get an advanced heads up on upcoming releases, along with the release emails that are sent to both user@ and dev@. The dev@ traffic is generally lower than user@, so pretty easy to spot votes &

Re: Security Updates

I usually install cron-apt for Ubuntu & Debian, forward and read root's email to be notified of all system upgrades, including Cassandra. There are likely other utilities for other operating systems, or just a cron script that checks for system update & emails would work, too. Also, it's

Security Updates

Hi, As a user of Cassandra I'd like to be able to get notified when there are security releases so that I can get my installation patched ASAP. For feature and patch releases I'm happy to come and look at the web page or trawl through some mail archives, but I'd like for security releases to

RE: confirm subscribe to user@cassandra.apache.org

Subscribe confirmed. Joe -Original Message- From: Rob Oxspring [mailto:roxspr...@imapmail.org] Sent: Wednesday, January 31, 2018 10:16 AM To: user@cassandra.apache.org Subject: Re: confirm subscribe to user@cassandra.apache.org Thanks, Rob Oxspring On Wed, Jan 31, 2018, at 6:15

Re: confirm subscribe to user@cassandra.apache.org

Thanks, Rob Oxspring On Wed, Jan 31, 2018, at 6:15 PM, user-h...@cassandra.apache.org wrote: > Hi! This is the ezmlm program. I'm managing the > user@cassandra.apache.org mailing list. > > To confirm that you would like > >roxspr...@imapmail.org > > added to the user mailing list,

Re: Nodes show different number of tokens than initially

> On Jan 31, 2018, at 12:35 AM, Oleksandr Shulgin > wrote: > >> On Tue, Jan 30, 2018 at 5:44 PM, Jeff Jirsa wrote: >> All DCs in a cluster use the same token space in the DHT, > > I can't believe my bloody eyes, but this seems to be true...

Re: CDC usability and future development

> > CDC provides only the mutation as opposed to the full column value, which > tends to be of limited use for us. Applications might want to know the full > column value, without having to issue a read back. We also see value in > being able to publish the full column value both before and after

Re: Upgrading sstables not using all available compaction slots on version 2.2

On Wed, Jan 24, 2018 at 10:40 AM, Oleksandr Shulgin < oleksandr.shul...@zalando.de> wrote: > Hello, > > In the process of upgrading our cluster from 2.1 to 2.2 we have triggered > the SSTable rewriting process like this: > > $ nodetool upgradesstables -j 4 # concurrent_compactors=5 > > Then if

Re: Slender Cassandra Cluster Project

Yes, I'd prefer Terraform too. On 2018-01-31 06:32:21, Michael Mior wrote: > While whatever format this comes out in would be helpful, you might want to > consider Terraform. 1Password recently published a blog post on their > experience with Terraform vs. CloudFormation. >

Re: Slender Cassandra Cluster Project

While whatever format this comes out in would be helpful, you might want to consider Terraform. 1Password recently published a blog post on their experience with Terraform vs. CloudFormation. https://blog.agilebits.com/2018/01/25/terraforming-1password/ -- Michael Mior mm...@apache.org

Re: Remote host closed connection during handshake SSL Cassandra 3.0.9

Hi Marcus >java version ? We use oracle-java8-jre the version 8u92. >TLSv1 disabled ? No it is not disable. We tried also with the version 1.2 Saludos Jean Carlo "The best way to predict the future is to invent it" Alan Kay On Wed, Jan 31, 2018 at 12:11 PM, Marcus Haarmann

Re: Remote host closed connection during handshake SSL Cassandra 3.0.9

java version ? TLSv1 disabled ? (TLSv1 should not be used any more, since it is outdated, but should work internally) Marcus Haarmann Von: "Jean Carlo" An: user@cassandra.apache.org Gesendet: Mittwoch, 31. Januar 2018 11:53:37 Betreff: Remote host closed

Remote host closed connection during handshake SSL Cassandra 3.0.9

Hello! I have a problem enabling inter-node encryption in cassandra 3.0.9 After I set my conf like that: server_encryption_options: internode_encryption: all keystore: /etc/certs/node1.keystore keystore_password: cassandra truststore: /etc/certs/node1.truststore

Re: Nodes show different number of tokens than initially

So the only reason that the new node would "steal" the token is if it started up earlier - which is based off how many heartbeats have occurred since entering NORMAL status on each node. I can't see any reason the new nodes would have higher generation numbers, so sounds likely there's a bug

Re: Nodes show different number of tokens than initially

On Wed, Jan 31, 2018 at 5:06 AM, Dikang Gu wrote: > What's the partitioner you use? We have logic to prevent duplicate tokens. > We are using the default Murmur3Partitioner. The problem arises from the fact that we manually allocating the tokens as described earlier. --

Re: Nodes show different number of tokens than initially

On Tue, Jan 30, 2018 at 5:44 PM, Jeff Jirsa wrote: > All DCs in a cluster use the same token space in the DHT, > I can't believe my bloody eyes, but this seems to be true... so token conflicts across datacenters are invalid config > If this is deemed invalid config why does