Thank you
On Tue, Aug 16, 2022 at 11:48 AM C. Scott Andreas
wrote:
> No downside at all for 3.x -> 4.x (however, Cassandra 3.x reading 2.1
> SSTables incurred a performance hit).
>
> Many users of Cassandra don't run upgradesstables after 3.x -> 4.x
> upgrades at all. It's not necessary to run u
No downside at all for 3.x -> 4.x (however, Cassandra 3.x reading 2.1 SSTables incurred a
performance hit).Many users of Cassandra don't run upgradesstables after 3.x -> 4.x upgrades at
all. It's not necessary to run until a hypothetical future time if/when support for reading
Cassandra 3.x SST
Thanks for the response and details. I am just curious about the below
statement mentioned in the doc. I am pretty confident that my clusters are
going to grow to 100+ nodes (same DC or combining all DCs). I am just
concerned that the doc says it is *not recommended for clusters over 50
nodes*.
16
Hello Cassandra users!
I'm dealing with the unexpected behavior of the tie resolution for the same
timestamp inserts. At least, unexpected for me.
The following simple repro under Cassandra 3.11.4 illustrates the question:
CREATE KEYSPACE the_test WITH replication = {'class': 'SimpleStrategy',
'r
Thank you Erick,
> it is going to be single-threaded by default so it will take a while to
get through all the sstables on dense nodes
Is there any downside if the upgradesstables take longer (example 1-2
days), other than I/O?
Also when is the upgradesstable get triggered? after every node is
up
As convenient as it is, there are a few caveats and it isn't a silver
bullet. The automatic feature will only kick in if there are no other
compactions scheduled. Also, it is going to be single-threaded by default
so it will take a while to get through all the sstables on dense nodes.
In contrast,
