Re: Backups eating up disk space

You can just delete them off the filesystem (rm) On Tue, Jan 10, 2017 at 8:02 AM Kunal Gangakhedkar wrote: > Hi all, > > We have a 3-node cassandra cluster with incremental backup set to true. > Each node has 1TB data volume that stores cassandra data. > > The load in

Re: Incremental Repair Migration

Reaper suppers incremental repair. On Mon, Jan 9, 2017 at 11:27 PM Amit Singh F wrote: > Hi Jonathan, > > > > Really appreciate your response. > > > > It will not be possible for us to move to Reaper as of now, we are in > process to migrate to Incremental repair. > >

Backups eating up disk space

Hi all, We have a 3-node cassandra cluster with incremental backup set to true. Each node has 1TB data volume that stores cassandra data. The load in the output of 'nodetool status' comes up at around 260GB each node. All our keyspaces use replication factor = 3. However, the df output shows

Re: Incremental Repair Migration

Hi Amit, You can try reaper, it makes repairs effortless. There are a host of other benefits but most importantly it offers a Single portal to manage & track ongoing as well as past repairs. For incremental repairs it breaks it into single segment per node, if you find that it's indeed the

Re: Backups eating up disk space

Thanks for quick reply, Jon. But, what about in case of node/cluster going down? Would there be data loss if I remove these files manually? How is it typically managed in production setups? What are the best-practices for the same? Do people take snapshots on each node before removing the

Documented CQL limits seem to be wrong (how are sets and lists implemented in the storage layer)

We're using Cassandra 2.2. This document lists a number of CQL limits. I'm particularly interested in the Collection limits for Set and List. If I've interpreted it correctly, the document states that values in Sets are limited to 65535 bytes.  This limit, as far as I know, exists because the

Re: Logs appear to contradict themselves during bootstrap steps

There was no need to assassinate in this case. 'nodetool removenode' worked fine (didn't want to risk losing data). I just don't follow the logic described by the logs. On Friday, January 6, 2017 5:45 PM, Edward Capriolo wrote: On Fri, Jan 6, 2017 at 6:45 PM,

Re: Trying to identify the cause of these errors.

Why don't you create a JIRA issue? Assertion errors, leaks and NPEs usually indicate a bug. This really should not happen. 2017-01-11 4:35 GMT+01:00 Gopal, Dhruva : > Any suggestions/recommendations? Anything will help at this point. Thanks! > > Regards, > > *DHRUVA

Re: Trying to identify the cause of these errors.

Any suggestions/recommendations? Anything will help at this point. Thanks! Regards, DHRUVA GOPAL sr. MANAGER, ENGINEERING REPORTING, ANALYTICS AND BIG DATA +1 408.325.2011 WORK +1 408.219.1094 MOBILE UNITED STATES dhruva.go...@aspect.com

RE: RemoveNode CPU Spike Question

Well, looking through logs I confirmed that my understanding below is correct, but would be good to hear from experts for sure  From: Anubhav Kale [mailto:anubhav.k...@microsoft.com] Sent: Tuesday, January 10, 2017 9:58 AM To: user@cassandra.apache.org Cc: Sean Usher

RemoveNode CPU Spike Question

Hello, Recently, I started noticing an interesting pattern. When I execute "removenode", a subset of the nodes that now own the tokens result it in a CPU spike / disk activity, and sometimes SSTables on those nodes shoot up. After looking through the code, it appears to me that below function

Re: Backups eating up disk space

If you remove the files from the backup directory, you would not have data loss in the case of a node going down. They're hard links to the same files that are in your data directory, and are created when an sstable is written to disk. At the time, they take up (almost) no space, so they aren't

Re: Strange issue wherein cassandra not being started from cron

On Tuesday, January 10, 2017, Jonathan Haddad wrote: > Last I checked, cron doesn't load the same, full environment you see when > you log in. Also, why put Cassandra on a cron? > On Mon, Jan 9, 2017 at 9:47 PM Bhuvan Rawal

Re: incremental repairs with -pr flag?

On 2016-10-24 13:39 (-0500), Alexander Dejanovski wrote: > Hi Sean, > > In order to mitigate its impact, anticompaction is not fully executed when > incremental repair is run with -pr. What you'll observe is that running > repair on all nodes with -pr will leave

Point in time restore

Hello, Are there any guides how to do a point-in-time restore for Cassandra? All I have seen is this: http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/configuration/configLogArchive_t.html

Re: Backups eating up disk space

Hello Kunal, I would take a look at the following configuration options in the Cassandra.yaml Common automatic backup settings Incremental_backups: http://docs.datastax.com/en/archived/cassandra/3.x/cassandra/configuration/configCassandra_yaml.html#configCassandra_yaml__incremental_backups

How to calculate CPU Utilisation on each node?

Hello, We are using Cassandra 2.1.13. We are calculating node CPU utilization using the below formula, CPUUsage = CPURate / (AvailableProcessors*100) CPURate = (x2-x1)/(t2-t1), where x2 and x1 are the values of the attribute ProcessCpuTime at the time t2 and t1 respectively.