It's more indicative of your nodes not able to service requests because
they are busy or overloaded. In my experience when you see the number
climbing because of peak load, the latency tends to show issues too. Other
symptoms of the load issue are higher-than-normal pending reads and writes.
The hi
I have seen cases where folks thought they were writing successfully to the
database but were really hitting timeouts due to an unhandled future in
their loading program. This may very well not be your issue but it's common
enough that I thought I would mention it.
Hope you get to the bottom of it
You need to see what's in that place, it could be:
1) Delete in the future (viewable with SELECT WRITETIME(column) ...). This
could be clock skew or using the wrong resolution timestamps (millis vs
micros)
2) Some form of corruption if you dont have compression + crc check chance.
It's possible (b
Oliver, by chance are you also doing a TTL on the data? Or maybe you've
already issued a DELETE that has a future timestamp?
The only other way I can see this happening is when the node's clocks
are skewed. Have you checked whether NTP hasn't drifted by a massive
amount? Cheers!
GOT QUESTIONS? Ap
Hello,
we are facing a strange issue in one of our Cassandra clusters.
We are using prepared statements to update a table with consistency local
quorum. When updating some tables it happes very often that data values are
not written to the database. When verifying the table using cqlsh (with
consi
I am working with Cassandra 3.11.2. In nodetool tpstats output I am
observing high number in "All Time Blocked" column for
"Native-Transport-Requests"
pool. I have two questions
1. Does a high number of "ALL Time Blocked" count impact client latency?
2. Does it increase off head memory overtime?
Also Reaper will skip the anticompaction phase which you might be going
through with nodetool (depending on your version of Cassandra).
That'll reduce the overall time spent on repair and will remove some
compaction pressure.
But as Erick said, unless you have past repairs to rely on and a stable
On Mon, Mar 23, 2020 at 5:49 AM Shishir Kumar
wrote:
> Hi,
>
> Is it possible to get/predict how much time it will take for *nodetool
> -pr *to complete on a node? Currently in one of my env (~800GB data per
> node in 6 node cluster), it is running since last 3 days.
>
Cassandra Reaper used to p
There's a lot of moving parts with repairs and how long it takes depends on
various factors including (but not limited to):
- how busy the nodes are
- how fast the CPUs are
- how fast the disks are
- how much network bandwidth is available
- how much data needs to be repaired
It's
