Agreed. I also think it is worthwhile to keep that code around. Given how widespread C* 3.x use is, I do not think it is worthwhile dropping support for those sstable formats at this time.
-Jeremiah > On Mar 14, 2023, at 9:36 AM, C. Scott Andreas <sc...@paradoxica.net> wrote: > > > I agree with Aleksey's view here. > > To expand on the final point he makes re: requiring SSTables be fully > rewritten prior to rev'ing from 4.x to 5.x (if the cluster previously ran > 3.x) – > > This would also invalidate incremental backups. Operators would either be > required to perform a full snapshot backup of each cluster to object storage > prior to upgrading from 4.x to 5.x; or to enumerate the contents of all > snapshots from an incremental backup series to ensure that no m*-series > SSTables were present prior to upgrading. > > If one failed to take on the work to do so, incremental backup snapshots > would not be restorable to a 5.x cluster if an m*-series SSTable were present. > > – Scott > >> On Mar 14, 2023, at 4:38 AM, Aleksey Yeshchenko <alek...@apple.com> wrote: >> >> >> Raising messaging service minimum, I have a less strong opinion on, but on >> dropping m* sstable code I’m strongly -1. >> >> 1. This is code on a rarely touched path >> 2. It’s very stable and battle tested at this point >> 3. Removing it doesn’t reduce much complexity at all, just a few branches >> are affected >> 4. Removing code comes with risk >> 5. There are third-party tools that I know of which benefit from a single C* >> jar that can read all relevant stable versions, and relevant here includes >> 3.0 ones >> >> Removing a little of battle-tested reliable code and a tinier amount of >> complexity is not, to me, a benefit enough to justify intentionally breaking >> perfectly good and useful functionality. >> >> Oh, to add to that - if an operator wishes to upgrade from 3.0 to 5.0, and >> we don’t support it directly, I think most of us are fine with the >> requirement to go through a 4.X release first. But it’s one thing to require >> a two rolling restarts (3.0 to 4.0, 4.0 to 5.0), it’s another to require the >> operator to upgrade every single m* sstable to n*. Especially when we have >> perfectly working code to read those. That’s incredibly wasteful. >> >> AY >> >>> On 13 Mar 2023, at 22:54, Mick Semb Wever <m...@apache.org> wrote: >>> >>> If we do not recommend and do not test direct upgrades from 3.x to >>> 5.x, we can clean up a fair bit by removing code related to sstable >>> formats m*, as Cassandra versions 4.x and 5.0 are all on sstable >>> formats n*. >>> >>> We don't allow mixed-version streaming, so it's not possible today to >>> stream any such older sstable format between nodes. This >>> compatibility-break impacts only node-local and/or offline. >>> >>> Some arguments raised to keep m* sstable formats are: >>> - offline cluster upgrade, e.g. direct from 3.x to 5.0, >>> - single-invocation sstableupgrade usage >>> - third-party tools based on the above >>> >>> Personally I am not in favour of keeping, or recommending users use, >>> code we don't test. >>> >>> An _example_ of the code that can be cleaned up is in the patch >>> attached to the ticket: >>> CASSANDRA-18312 – Drop support for sstable formats before `na` >>> >>> What do you think? > > > > >
