'4', 'tombstone_compaction_interval':
'86400', 'unchecked_tombstone_compaction': 'true',
'unsafe_aggressive_sstable_expiration': 'true'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND default_time_to_live = 86400
AND extensions = {}
AND gc_grace_seconds = 3600
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
Our application has logic that Monday to Thurs records has a TTL of one day.
Friday records has a TTL of 3 days.
The Monday to Thursday records are cleaning up properly. It is always the
Friday's data seem to have extended expires_at.
Thanks in advance for anyone who can provide some pointers on where to check
for problem.
Eric Wong
Hi all:
I just enabled full_query_logging_option in my Cassandra.yaml and run nodetool
enablefullquerylog. So far so good.
But when I use fqltool to view the captured binary file using fqltool dump, I
saw that all query statements it captured do not contain the actual value.
They all show u
Hi all:
I am using Cassandra 4.0 and a table called 'minute' is configured to use TWCS.
Since it is TWCS, I do not have cassandra-reaper to perform any repair of the
table. There is also no manual compaction performed on the table.
When we insert data into the db, we set a TTL of one day from
Oh. So our data is all messed up now because of the "nodetool compact" I ran.
Hi Erick. Thanks for the quick reply.
I just want to be sure about compact. I saw Cassandra will do compaction by
itself even when I do not run "nodetool compact" manually (nodetool
compactionstats always has some
Hi:
We need some help on cassandra repair and compact for a table that uses TWCS.
We are running cassandra 4.0-rc1. A database called test_db, biggest table
"minute_rate", storing time-series data. It has the following configuration:
CREATE TABLE test_db.minute_rate (
market smallint,
