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.– ScottOn 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 path2. It’s very stable and battle tested at this point3. Removing it doesn’t
reduce much complexity at all, just a few branches are affected4. Removing code comes with
risk5. 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 onesRemoving 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.AYOn 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 to5.x, we can clean up a fair bit by removing code related to
sstableformats m*, as Cassandra versions 4.x and 5.0 are all on sstableformats n*.We don't
allow mixed-version streaming, so it's not possible today tostream any such older sstable
format between nodes. Thiscompatibility-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
abovePersonally 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 patchattached to the
ticket:CASSANDRA-18312 – Drop support for sstable formats before `na`What do you think?
