Hi Robert,
I haven't yet asked that question in IRC channel. We are generating regular
sstables in CF so that's not a concern. Important part is that we need to
understand tombstone_threshold property because we think that it's very
important once we have done major compaction. How the huge tabl
On Mon, Jun 1, 2015 at 11:25 AM, Anuj Wadehra
wrote:
> As per the algorithm shared in the CASSANDRA 6654, I understand that
> tombstone_threshold property only comes into picture if you have expirying
> columns and it wont have any effect if you have manually deleted rows in
> cf. Is my understan
any other sstable
Thanks
Anuj
Sent from Yahoo Mail on Android
From:"Robert Coli"
Date:Mon, 1 Jun, 2015 at 10:56 pm
Subject:Re: Minor Compactions Not Triggered
On Sun, May 31, 2015 at 11:37 AM, Anuj Wadehra wrote:
2. We thought that CQL compaction subproperty of tombstone_thre
On Sun, May 31, 2015 at 11:37 AM, Anuj Wadehra
wrote:
> 2. We thought that CQL compaction subproperty of *tombstone_threshold*
> will help us after major compactions. This property will ensure that even
> if we have one huge sstable, once tombstone threshold of 20% has reached,
> sstables will be
Hi,
I am using Cassandra 2.0.3 and we use STCS for all CFs. We have recently faced
an issue where sstable count of certain CFs went into THOUSANDS. We realized
that every week, when "repair -pr" ran on each node, it created 50+ tiny
sstables of around 1kb. These tables were never compacted durin
