We have a 14 node Cassandra cluster 3.11.1. For some odd reason
intermittently we see the following error
ERROR [HintsDispatcher:1] 2018-04-06 16:26:44,423
CassandraDaemon.java:228 - Exception in thread
I spent some time in code (trunk) to understand it better. If I understood
it correctly DiskBoundaryManager.getDiskBoundaries() method does the
partition and it has nothing to do with the compaction strategy. Is it
cassandra.yaml states that "Directories where Cassandra should store data
Yes, the commit log show that we built it out f919cf4a4 which we used
later locally to build it.
I realize that using release artifact is suggested. We tried even
3.11.1 ( official release) and where able to reproduce this issue on
14 node cluster
On Mon, Apr 9, 2018 at 12:11 PM, Michael Shuler
> cassandra.yaml states that "Directories where Cassandra should store data on
> disk. Cassandra will spread data evenly across them, subject to the
> granularity of the configured compaction strategy.". I feel it is not correct
> anymore. Is it worth updating the doc?
In fact this changed
Paulo, thanks for the confirmation. I had raised a ticket for this.
On Tue, Apr 10, 2018 at 2:37 AM, Paulo Motta
> > cassandra.yaml states that "Directories where Cassandra should store
> data on disk.
If there were no other messages about anti-compaction similar to:
> SSTable YYY (ranges) will be anticompacted on range [range]
Then no anti-compaction needed to occur and yes, it was not the cause.
On 5 April 2018 at 13:52, Dmitry Simonov wrote:
> Hi, Evelyn!
On 04/09/2018 01:43 PM, Vineet G H wrote:
> Hello All,
> We have a 14 node Cassandra cluster 3.11.1. For some odd reason
> intermittently we see the following error
> ERROR [HintsDispatcher:1] 2018-04-06 16:26:44,423
> CassandraDaemon.java:228 - Exception in thread
I am using 3.11.0 and I have the following table.
CREATE TABLE summary_5m (
PRIMARY KEY ((service_key), hash_key, instance_hash, collected_time)
And I can sum
Challenging the possibilty that the latancy is related with the number of
record is a good guess indeed. It might be, but I don't think so, given the
max 50 Mb partition size. This should should allow to catch a partition of
this size, probably below 1 second.
It is possible to trace a query
No, sorting by column other than clustering column is not possible
On Mon, Apr 9, 2018 at 11:42 AM, Eunsu Kim wrote:
> Hello, everyone.
> I am using 3.11.0 and I have the following table.
> CREATE TABLE summary_5m (
> service_key text,
> hash_key int,
Mail list logo