Re: Alter table gc_grace_seconds

Hi, On Mon, Oct 2, 2017 at 5:55 AM Varun Barala wrote: > *select gc_grace_seconds from system_schema.tables where keyspace_name = > 'keyspace' and table_name = 'number_item;* > cassandra@cqlsh:mat> DESCRIBE TABLE mat.number_item; CREATE TABLE mat.number_item (

Re: Alter table gc_grace_seconds

Can you share result of query:- *select gc_grace_seconds from system_schema.tables where keyspace_name = 'keyspace' and table_name = 'number_item;* Thanks!! On Mon, Oct 2, 2017 at 3:42 AM, Gábor Auth wrote: > Hi, > > On Sun, Oct 1, 2017 at 9:36 PM Varun Barala

Re:

What specifically are you looking to monitor? As per above, Datadog has superb components for monitoring, and no need do develop and support anything, for a price of course. I have found management sometimes sees devops resources as pretty low cost (pay for 40, get 70 hours work per week). Depends

Re: space left for compaction

Hi Avi, Actually, in Thomas' example you would need an additional 100G of free disk space to complete the compaction, in the worst-case situation (the worst-case would be that neither input SSTable contains any overlapping data or tombstones, therefore the output SSTable would also be roughly

RE: space left for compaction

Hi Thomas , So IIUC in this case you should leave at least 50G for compaction (half of the sstables size). Is that makes sense? Cheers Avi On Oct 1, 2017 11:39 AM, "Steinmaurer, Thomas" < thomas.steinmau...@dynatrace.com> wrote: Hi, half of free space does not make sense. Imagine your

Re: Alter table gc_grace_seconds

Hi, On Sun, Oct 1, 2017 at 9:36 PM Varun Barala wrote: > * You should not try on real clusters directly. > Why not? :) Did you change gc_grace for all column families? > Not, only on the `number_item` CF. > But not in the `number_item` CF... :( > Could you please

Re: Alter table gc_grace_seconds

* You should not try on real clusters directly. Did you change gc_grace for all column families? > But not in the `number_item` CF... :( Could you please explain? Thanks!! On Mon, Oct 2, 2017 at 2:24 AM, Gábor Auth wrote: > Hi, > > On Sun, Oct 1, 2017 at 7:44 PM Varun

Re: Alter table gc_grace_seconds

Hi, On Sun, Oct 1, 2017 at 7:44 PM Varun Barala wrote: > Sorry If I misunderstood the situation. > Ok, I'm confused... :/ I've just tested it on the same cluster and the compact removed the marked_deleted rows. But not in the `number_item` CF... :( Cassandra 3.11.0,

Re: Alter table gc_grace_seconds

Sorry If I misunderstood the situation. { "type" : "row", "position" : 146160, "clustering" : [ "humidity", "97781fd0-9dab-11e7-a3d5-7f6ef9a844c7" ], "deletion_info" : { "marked_deleted" : "2017-09-25T11:51:19.165276Z", "local_delete_time" : "2017-09-25T11:51:19Z" }, "cells" : [ ] }

Re: Alter table gc_grace_seconds

Hi, On Sun, Oct 1, 2017 at 6:53 PM Jonathan Haddad wrote: > The TTL is applied to the cells on insert. Changing it doesn't change the > TTL on data that was inserted previously. > Is there any way to purge out these tombstoned data? Bye, Gábor Auth

Re: Alter table gc_grace_seconds

Hi, On Sun, Oct 1, 2017 at 6:53 PM Jonathan Haddad wrote: > The TTL is applied to the cells on insert. Changing it doesn't change the > TTL on data that was inserted previously. > Oh! So that the tombstoned cell's TTL is equals with the CF's gc_grace_seconds value and the

Re:

I've seen successful AWS deployments in the past with Datadog and Graphite+Seyren On Sun, Oct 1, 2017 at 9:14 AM, Bill Walters wrote: > Hi All, > > I need some help with deploying a monitoring and alerting system for our > new Cassandra 3.0.4 cluster that we are

Re: Alter table gc_grace_seconds

The TTL is applied to the cells on insert. Changing it doesn't change the TTL on data that was inserted previously. On Sun, Oct 1, 2017 at 6:23 AM Gábor Auth wrote: > Hi, > > The `alter table number_item with gc_grace_seconds = 3600;` is sets the > grace seconds of

Re: Alter table gc_grace_seconds

* Which C* version are you using? * How many nodes are there in this cluster? These tombstones will not be deleted if they are not older than gc_grace_seconds. On Sun, Oct 1, 2017 at 10:14 PM, Gábor Auth wrote: > Hi, > > On Sun, Oct 1, 2017 at 3:44 PM Varun Barala

Re:

AWS is a good choice, you will have to use Amazon Web Services EC2 . Regards On Sunday, October 1, 2017, Bill Walters wrote: > Hi All, > > I need some help with deploying a monitoring and alerting system for our > new Cassandra 3.0.4 cluster that we are setting up in

[no subject]

Hi All, I need some help with deploying a monitoring and alerting system for our new Cassandra 3.0.4 cluster that we are setting up in AWS East region. I have a good experience with Cassandra as we are running some 2.0.16 clusters in production on our on-prem servers. We use Nagios tool to

Re: Alter table gc_grace_seconds

Hi, On Sun, Oct 1, 2017 at 3:44 PM Varun Barala wrote: > This is the property of table and It's not written in sstables. If you > change gc_grace, It'll get applied for all the data. > Hm... I've migrated lot of data from `number_item` to `measurement` CF because of

Re: Alter table gc_grace_seconds

Hi, This is the property of table and It's not written in sstables. If you change gc_grace, It'll get applied for all the data. Thanks!! C* stores this info inside schema_columnfamilies Regards, Varun Barala On Sun, Oct 1, 2017 at 9:23 PM, Gábor Auth wrote: > Hi, > > The

Alter table gc_grace_seconds

Hi, The `alter table number_item with gc_grace_seconds = 3600;` is sets the grace seconds of tombstones of the future modification of number_item column family or affects all existing data? Bye, Gábor Auth

Cassandra 3.11.1 (snapshot build) - io.netty.util.Recycler$Stack memory leak

Hello, we were facing a memory leak with 3.11.0 (https://issues.apache.org/jira/browse/CASSANDRA-13754) thus upgraded our loadtest environment to a snapshot build of 3.11.1. Having it running for > 48 hrs now, we still see a steady increase on heap utilization. Eclipse memory analyzer shows

RE: space left for compaction

Hi, half of free space does not make sense. Imagine your SSTables need 100G space and you have 20G free disk. Compaction won't be able to do its job with 10G. Half free of total disk makes more sense and is what you need for a major compaction worst case. Thomas From: Peng Xiao