Thank you On Tue, Aug 16, 2022 at 11:48 AM C. Scott Andreas <sc...@paradoxica.net> 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 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. > > – Scott > > On 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 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 > 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! >> >>> >>> >
