Thank you all. I will try different options and will let you know which one
worked for my case.
On Wed, Mar 23, 2022 at 3:25 AM Bowen Song wrote:
> I remember we had the same issue back in the Cassandra 2.x days, and
> restarting the affected node only makes the issue go away temporarily. The
>
I think this has a much simpler answer: GNU tar interprets inode changes
as "changes" as well as block contents. This includes the hardlink count.
I actually ended up working around it by using bsdtar, which doesn't
interpret hardlink count changes as a change to be concerned about.
On Tue, Mar
Since you still have two SSTables after a major compaction, my best
guess is one of them is repaired and the other is unrepaired. If a
partition exists in both SSTable, and only one of them is a tombstone,
the tombstone must be kept to avoid resurrecting the data from the other
SSTable. To get
Hi all,
I have a table (with default gc_grace_seconds) where we have some row
tombstones created. Currently there are 2 sstables for this.
When we check the sstablemetadata, we found Estimated droppable tombstones:
0.689(for sstable1) and 1.094(for sstable2)
After executing nodetool compact on thi
Hello,
I am trying to create a UDF based on custom methods.
So I set enable_user_defined_functions to true and added a jar in
"/usr/share/cassandra/lib/" folder on every node, restarted the nodes and I
can see from the command line that the jar is indeed used (in the classpath
with -cp).
But when
I remember we had the same issue back in the Cassandra 2.x days, and
restarting the affected node only makes the issue go away temporarily.
The issue we had was "fixed" by adding
"-Dcassandra.max_queued_native_transport_requests=4096" to the JVM
options. I dug that option out from our old Ansib
