Hi Jordan,
thank you for accepting this as an issue.
I will follow the ticket.
Best regards,
Roman
On 30 May 2018 at 11:40, Jordan West wrote:
> Hi Roman,
>
> I was able to reproduce the issue you described. I filed
> https://issues.apache.org/jira/browse/CASSANDRA-14479. More details there.
Hi Roman,
I was able to reproduce the issue you described. I filed
https://issues.apache.org/jira/browse/CASSANDRA-14479. More details there.
Thanks for reporting!
Jordan
On Wed, May 23, 2018 at 12:06 AM, Roman Bielik <
roman.bie...@openmindnetworks.com> wrote:
> Hi,
>
> I apologise for a
Hi,
I apologise for a late response I wanted to run some further tests so I can
provide more information to you.
@Jeff, no I don't set the "only_purge_repaired_tombstone" option. It should
be default: False.
But no I don't run repairs during the tests.
@Eric, I understand that rapid
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
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,
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
