RE: Unable to track compaction completion

Hi Rajsekhar, I think monitoring the CompactionManagerMBean is what you need. Kenneth Brotman From: Rajsekhar Mallick [mailto:raj.mallic...@gmail.com] Sent: Friday, February 15, 2019 8:59 AM To: user@cassandra.apache.org Subject: Unable to track compaction completion Hello team,

RE: tombstones threshold warning

There is another good article called Common Problems with Cassandra Tombstones by Alla Babkina at https://opencredo.com/blogs/cassandra-tombstones-common-issues/ . It says interesting stuff like: 1. You can get tombstones without deleting anything 2. Inserting null values

RE: tombstones threshold warning

Hi Ayub, Is everything flushing to SSTables? It has to be somewhere right? So is it in the memtables? Or is it that there are tombstones that are sometimes detected and sometimes not detected as described in the very detailed article on The Last Pickle by Alex Dejanovski called

RE: Looking for feedback on automated root-cause system

Any information you can share on the inputs it needs/uses would be helpful. Kenneth Brotman From: daemeon reiydelle [mailto:daeme...@gmail.com] Sent: Tuesday, February 19, 2019 4:27 PM To: user Subject: Re: Looking for feedback on automated root-cause system Welcome to the world of

Re: Looking for feedback on automated root-cause system

Welcome to the world of testing predictive analytics. I will pass this on to my folks at Accenture, know of a couple of C* clients we run, wondering what you had in mind? *Daemeon C.M. Reiydelle* *email: daeme...@gmail.com * *San Francisco 1.415.501.0198/London 44 020 8144 9872/Skype

Looking for feedback on automated root-cause system

Howdy, I’ve been engaged in the Cassandra user community for a long time, almost 8 years, and have worked on hundreds of Cassandra deployments. One of the things I’ve noticed in myself and a lot of my peers that have done consulting, support or worked on really big deployments is that we get

Re: Restore a table with dropped columns to a new cluster fails

You can also manually add the dropped column to the appropriate table to eliminate the issue. Has to be done by a human, a new cluster would have no way of learning about a dropped column, and the missing metadata cannot be inferred. On Tue, Feb 19, 2019 at 10:58 AM Elliott Sims wrote: > When

Re: Restore a table with dropped columns to a new cluster fails

When a snapshot is taken, it includes a "schema.cql" file. That should be sufficient to restore whatever you need to restore. I'd argue that neither automatically resurrecting a dropped table nor silently failing to restore it is a good behavior, so it's not unreasonable to have the user

Restore a table with dropped columns to a new cluster fails

Hi, I would like to bring this issue to your attention. Link to the ticket: https://issues.apache.org/jira/browse/CASSANDRA-14336 Basically if a table contains dropped columns and you try to restore a snapshot to a new cluster, that will