Hey,
@Tom I just wanted to clarify when I mention workload in the last email I meant
it as the amount of requests the cluster has to serve.
Gediminas
From: Tom van der Woerdt
Sent: Wednesday, October 28, 2020 14:35
To: user
Subject: [EXTERNAL] Re: Running and Managing Large Cassandra
receiving in terms of local C* reads, writes and client
> requests as well?
>
>
>
> You mention repairs, how do you run them?
>
>
>
> Gediminas
>
>
>
> *From:* Tom van der Woerdt
> *Sent:* Wednesday, October 28, 2020 14:35
> *To:* user
> *Subjec
Subject: [EXTERNAL] Re: Running and Managing Large Cassandra Clusters
Heya,
We're running version 3.11.7, can't use 3.11.8 as it won't even start
(CASSANDRA-16091). Our policy is to use LCS for everything unless there's a
good argument for a different compaction strategy (I
Heya,
We're running version 3.11.7, can't use 3.11.8 as it won't even start
(CASSANDRA-16091). Our policy is to use LCS for everything unless there's a
good argument for a different compaction strategy (I don't think we have
*any* STCS at all other than system keyspaces). Since our nodes are mostl
A few questions for you Tom if you have 30 seconds and care to disclose:
1. What version of C*?
2. What compaction strategy?
3. What's core count allocated per C* node?
4. Gossip give you any headaches / you have to be delicate there or does
it behave itself?
Context: pmc/committer
Does 360 count? :-)
num_tokens is 16, works fine (had 256 on a 300 node cluster as well, not
too many problems either). Roughly 2.5TB per node, running on-prem on
reasonably stable hardware so replacements end up happening once a week at
most, and there's no particular change needed in the automat
