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!
>
> I've found the following me
Paulo, thanks for the confirmation. I had raised a ticket for this.
https://issues.apache.org/jira/browse/CASSANDRA-14372
On Tue, Apr 10, 2018 at 2:37 AM, Paulo Motta
wrote:
> > cassandra.yaml states that "Directories where Cassandra should store
> data on disk. Cassandra will spread data eve
> 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 aft
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
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
correct?
cassandra.yaml states that "Directories where Cassandra should store data
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
> Thread[HintsDispatcher:1,
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
Thread[HintsDispatcher:1,1,main]
org.apache.cassandra.io.FSReadError: java.io.IOExc
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,
> instance_hash int,
> c
Hello, everyone.
I am using 3.11.0 and I have the following table.
CREATE TABLE summary_5m (
service_key text,
hash_key int,
instance_hash int,
collected_time timestamp,
count int,
PRIMARY KEY ((service_key), hash_key, instance_hash, collected_time)
)
And I can sum count
Hi,
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
10 matches
Mail list logo