Unsubscribe

Cordialement, Eric ROUVREAU Prestataire Expert technique SGDB - CDC Middleware Enedis - Direction des Systèmes d'Information Pôle AUDES - Opérateur Informatique - Département Ingénierie et Infrastructures - (DIGIT) - Groupe Infrastructures applicatives 117

Re: Backups eating up disk space

Hi all, Is it safe to delete the backup folders from various CFs from 'system' keyspace too? I seem to have missed them in the last cleanup - and now, the size_estimates and compactions_in_progress seem to have grown large ( >200G and ~6G respectively). Can I remove them too? Thanks, Kunal On

Re: Which compaction strategy when modeling a dumb set

Do you also store events in Cassandra? If yes, why not to add "processed" flag to existing table(s), and fetch non-processed events with single SELECT? Best regards, Vladimir Yudovin, Winguzone - Cloud Cassandra Hosting On Fri, 24 Feb 2017 06:24:09 -0500 Vincent Rischmann

Re: Attached profiled data but need help understanding it

Also Attached is a flamed graph generated from a thread dump. On Mon, Feb 27, 2017 at 2:32 AM, Kant Kodali wrote: > Hi, > > Attached are the stats of my Cassandra node running on a 4-core CPU. I am > using sjk-plus tool for the first time so what are the things I should >

Re: Which compaction strategy when modeling a dumb set

No I don't store events in Cassandra. The real thing I'm doing is couting stuff: each event has a type, a user associated with it, some other metadata. When I process an event I need to increment those counters only if the event hasn't already been processed. Our input event stream is Kafka and

Unsubscribe

Re: Unsubscribe

Please send mail to. user-unsubscr...@cassandra.apache.org -- Ashish Disawal 2017-02-27 17:58 GMT+05:30 ROUVREAU Eric - externe < eric-externe.rouvr...@enedis.fr>: > > > > > Cordialement, > > *Eric **ROUVREAU* > > Prestataire Expert technique SGDB - CDC Middleware > > *Enedis* - Direction des

Re: Unsubscribe

Please send mail to. user-unsubscr...@cassandra.apache.org -- Ashish Disawal On Mon, Feb 27, 2017 at 5:57 PM, Sujeet Kumar wrote: >

Re: Is periodic manual repair necessary?

There are 4 anti entropy systems in cassandra. Hinted handoff Read repair Commit logs Repair commamd All are basically best effort. Commit logs get corrupt and only flush periodically. Bits rot on disk and while crossing networks network Read repair is async and only happens randomly Hinted

Re: Backups eating up disk space

Yes, you can. It's just hardlinks to tables files, so if some file is still active it will remain intact. Best regards, Vladimir Yudovin, Winguzone - Cloud Cassandra Hosting On Mon, 27 Feb 2017 09:27:50 -0500 Kunal Gangakhedkar kgangakhed...@gmail.com wrote Hi all, Is

Re: Which compaction strategy when modeling a dumb set

Do you update this table when an event is processed? If yes, it is considered a good practice for Cassandra. I read somewhere that using Cassandra as a queuing table is anti pattern. From: Vincent Rischmann Sent: Friday, February

Re: Which compaction strategy when modeling a dumb set

This is not a queue pattern and I'd recommend LCS for better read performance. 2017-02-27 16:06 GMT+01:00 Rakesh Kumar : > Do you update this table when an event is processed? If yes, it is > considered a good practice for Cassandra. I read somewhere that using >

Is periodic manual repair necessary?

Suppose I have an application, where there are no deletes, only 5-10% of rows being occasionally updated (and that too only once) and a lot of reads. Furthermore, I have replication = 3 and both read and write are configured for local_quorum. Occasionally, servers do go into maintenance. I

Re: Which compaction strategy when modeling a dumb set

typo: " If yes, it is considered a good practice for Cassandra" should read as " If yes, is it considered a good practice for Cassandra ?" From: Rakesh Kumar Sent: Monday, February 27, 2017 10:06 To: user@cassandra.apache.org

Re: Attached profiled data but need help understanding it

On Mon, Feb 27, 2017 at 10:30 AM, Romain Hardouin wrote: > Hi, > > Regarding shared pool workers see CASSANDRA-11966. You may have to > backport it depending on your Cassandra version. > *we are currently using 3.0.9. should we use 3.8 or 3.10?* > > Did you try to

Re: Is periodic manual repair necessary?

Are you running multi dc? Skickat från min iPad > 27 feb. 2017 kl. 16:08 skrev Thakrar, Jayesh : > > Suppose I have an application, where there are no deletes, only 5-10% of rows > being occasionally updated (and that too only once) and a lot of reads. > >

Re: Is periodic manual repair necessary?

A TTL is technically similar to a delete - in the end both create tombstones. If you want to eliminate the possibility of resurrected deleted data, you should run repairs. If you can guarantuee a 100% that data is read-repaired before gc_grace_seconds after the data has been TTL'ed, you won't

Re: secondary index on static column

Hi, Sorry for the delay, I created a ticket with steps to reproduce the issue:  https://issues.apache.org/jira/browse/CASSANDRA-13277 Best, Romain Le Jeudi 2 février 2017 16h53, Micha a écrit : Hi, it's a 3.9, installed on a jessie system. For me it's like

Re: Attached profiled data but need help understanding it

Hi, Regarding shared pool workers see CASSANDRA-11966. You may have to backport it depending on your Cassandra version.  Did you try to lower compaction throughput to see if it helps? Be sure to keep an eye on pending compactions, SSTables count and SSTable per read of course. "alloc" is the

Re: Attached profiled data but need help understanding it

Hi! My answers are inline. On Mon, Feb 27, 2017 at 11:48 AM, Kant Kodali wrote: > > > On Mon, Feb 27, 2017 at 10:30 AM, Romain Hardouin > wrote: > >> Hi, >> >> Regarding shared pool workers see CASSANDRA-11966. You may have to >> backport it depending on

Re: Is periodic manual repair necessary?

Thanks Roth and Oskar for your quick responses. This is a single datacenter, multi-rack setup. > A TTL is technically similar to a delete - in the end both create tombstones. >If you want to eliminate the possibility of resurrected deleted data, you >should run repairs. So why do I need to