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 SSTables is removed from Cassandra. One of the most common reasons to avoid running
upgradesstables is because doing so causes 100% churn of the data files, meaning your backup
processes will need to upload a full copy of the data. Allowing SSTables to organically churn into
the new version via compaction avoids this.If you're upgrading from 3.x to 4.x, don't feel like you
have to - but it does avoid the need to run upgradesstables in a hypothetical distant future.–
ScottOn Aug 16, 2022, at 6:32 AM, Jai Bheemsen Rao Dhanwada <jaibheem...@gmail.com>
wrote: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 nodesIs 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 upgraded or it will kick in only when all the nodes in the cluster upgraded to 4.0.x?On Tue, Aug
16, 2022 at 2:12 AM Erick Ramirez <erickramire...@apache.org> wrote: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, you'll have a bit more
control if you manually upgrade the sstables. For example, you can schedule the upgrade during low
traffic periods so reads are not competing with compactions for IO. Cheers!
