Though it is not required to run upgradesstables, but upgradesstables -a will re-write the file to kick out tombstones, in sizeTieredcompaction, the largest files may stay a long time to wait for the next compaction to kick out tombstones. So it really depends, to run it or not, usually upgrades have a change window, applications may be no load or less load, why don't take the chance to run it.
Regards, Jim On Tue, Aug 16, 2022 at 3:17 PM Jai Bheemsen Rao Dhanwada < jaibheem...@gmail.com> wrote: > 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! >>> >>>> >>>> >>
