secondary index table - tombstones surviving compactions

Hi, I have a Cassandra 3.11 table (with compact storage) and using secondary indices with rather unique data stored in the indexed columns. There are many inserts and deletes, so in order to avoid tombstones piling up I'm re-using primary keys from a pool (which works fine). I'm aware that this

Re: Hi-Rez of Apache Cassandra logo??

Super cool. Thanks folks! On Fri, May 18, 2018, 5:57 PM Michael Shuler wrote: > Nice, thanks! > > I went ahead and committed the files to SVN. I hope that was OK, Scott :) > > https://svn.apache.org/repos/asf/cassandra/logo/ > >

Review needed: Resume compresed hints delivery broken in Cassandra 3.0

Hi, If someone have the time to review CASSANDRA-14419: Resume compresed hints delivery broken it would be much appreciated. Resume hint delivery is broken in the 3.0 branch, the same problem existed in 3.x but was fixed by

Re: secondary index table - tombstones surviving compactions

This would matter for the base table, but would be less likely for the secondary index, where the partition key is the value of the base row Roman: there’s a config option related to only purging repaired tombstones - do you have that enabled ? If so, are you running repairs? -- Jeff Jirsa

Re: secondary index table - tombstones surviving compactions

The answer to Question 3 is "yes." One of the more subtle points about tombstones is that Cassandra won't remove them during compaction if there is a bloom filter on any SSTable on that replica indicating that it contains the same partition (not primary) key. Even if it is older than gc_grace,

Re: Hi-Rez of Apache Cassandra logo??

If you need any modifications (color, vector conversions, etc.) hit me up. Gary. On Thu, May 17, 2018 at 11:45 PM Nate McCall wrote: > I'm looking for a hi-rez source of 'the eye' with "Apache Cassandra" > (that last part is important) basically what we have on the