It seems “An alternative solution is to implement/complete CASSANDRA-8110 <https://issues.apache.org/jira/browse/CASSANDRA-8110>” can give us more options if it is finished😉
Branimir Lambov <blam...@apache.org>于2023年2月20日 周一下午11:03写道： > Hi everyone, > > There has been a discussion lately about changes to the sstable format in > the context of being able to abort a cluster upgrade, and the fact that > changes to sstables can prevent downgraded nodes from reading any data > written during their temporary operation with the new version. > > Most of the discussion is in CASSANDRA-18134 > <https://issues.apache.org/jira/browse/CASSANDRA-18134>, and is spreading > into CASSANDRA-14277 > <https://issues.apache.org/jira/browse/CASSANDRA-14227> and > CASSANDRA-17698 <https://issues.apache.org/jira/browse/CASSANDRA-17698>, > none of which is a good place to discuss the topic seriously. > > Downgradability is a worthy goal and is listed in the current roadmap. I > would like to open a discussion here on how it would be achieved. > > My understanding of what has been suggested so far translates to: > - avoid changes to sstable formats; > - if there are changes, implement them in a way that is > backwards-compatible, e.g. by duplicating data, so that a new version is > presented in a component or portion of a component that legacy nodes will > not try to read; > - if the latter is not feasible, make sure the changes are only applied if > a feature flag has been enabled. > > To me this approach introduces several risks: > - it bloats file and parsing complexity; > - it discourages improvement (e.g. CASSANDRA-17698 is no longer a LHF > ticket once this requirement is in place); > - it needs care to avoid risky solutions to address technical issues with > the format versioning (e.g. staying on n-versions for 5.0 and needing a > bump for a 4.1 bugfix might require porting over support for new features); > - it requires separate and uncoordinated solutions to the problem and > switching mechanisms for each individual change. > > An alternative solution is to implement/complete CASSANDRA-8110 > <https://issues.apache.org/jira/browse/CASSANDRA-8110>, which provides a > method of writing sstables for a target version. During upgrades, a node > could be set to produce sstables corresponding to the older version, and > there is a very straightforward way to implement modifications to formats > like the tickets above to conform to its requirements. > > What do people think should be the way forward? > > Regards, > Branimir > > > -- you are the apple of my eye !
