The easiest option here, though still unpleasant, is sstabledump to json and look at the tombstone
Usually when this happens it’s because something unexpected is happening - actually writing nulls or doing deleted or weird short TTLs without realizing it
Dump the sstable and look, it’ll be faster than mailing list guessing
On Oct 9, 2024, at 12:07 PM, Jon Haddad <j...@rustyrazorblade.com> wrote:
Overwriting non collections does not generate tombstones on compaction.
Hi, Naman: How does the client side load large amounts of data ? Most likely it has a retry policy, either by tool's default or by setting. If it has a retry policy, will have duplicated records, after compaction, will have tombstones.
Another possibility, client set ttl, it will override table's ttl setting, you may look at a few example data by ttl(pk_column_name), writetime(pk_column_name) from the table. Sometimes, a surprise.
Thanks,
James
Are you using collections?
Hi Community, We are currently using Cassandra version 4.1.3 and have encountered an issue related to tombstone generation. We have two tables storing monthly data: table_september and table_october. Each table has a TTL of 30 days. For the month of October, data is being inserted into the table_october, and we are seeing the following warning at the start of the month: WARN [CompactionExecutor:22030] 2024-10-07 16:37:16,376 BigTableWriter.java:274 - Writing 102594 tombstones to table_october
Here are a few things to note: - No update or delete operations are being performed on the table.
- TTL is correctly set to 30 days, and the data being inserted is within this time range, so the TTL shouldn't be the reason for tombstones.
- No null values are being inserted in any column.
We are still seeing tombstones being generated for the October table. Does anyone have insights into what could be causing these tombstones, or how we can prevent this from happening? Any help would be greatly appreciated! Thanks in advance.
|
