Re: Downgradability

I'd like to mention CASSANDRA-17056 (CEP-17) here as it aims to introduce multiple sstable formats support. It allows for providing an implementation of SSTableFormat along with SSTableReader and SSTableWriter. That could be extended easily to support different implementations for certain version

Re: [EXTERNAL] Re: Cassandra CI Status 2023-01-07

Hi all : Here comes Cassandra CI status for 2023-2-13 - 2023-2-17 : *** CASSANDRA-18274 - Test Failures:org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression -linked in 4.1 Other tests below are time out

Re: Downgradability

Hi, What I wanted to address in my comment in CASSANDRA-8110( https://issues.apache.org/jira/browse/CASSANDRA-8110?focusedCommentId=17641705=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17641705) is to focus on better upgrade experience. Upgrading the cluster can be

Re: Downgradability

FWIW I think 8110 is the right approach, even if it isn’t a panacea. We will have to eventually also tackle system schema changes (probably not hard), and may have to think a little carefully about other things, eg with TTLs the format change is only the contract about what values can be present,

Re: Downgradability

In a self-organising community, things that aren’t self-policed naturally end up policed in an adhoc manner, and with difficulty. I’m not sure that’s the same as arbitrary enforcement. It seems to me the real issue is nobody noticed this was agreed and/or forgot and didn’t think about it much. 

Re: Downgradability

I'm not even convinced even 8110 addresses this - just writing sstables in old versions won't help if we ever add things like new types or new types of collections without other control abilities. Claude's other email in another thread a few hours ago talks about some of these surprises -

Re: Downgradability

I’m a big fan of maintaining backward compatibility. Downgradability implies that we could potentially roll back an upgrade at any time. While I don’t think we need to retain the ability to downgrade in perpetuity it would be a good objective to maintain strict backward compatibility and therefore

Re: Downgradability

There has been progress on https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-8928 Which is similar to what datastax does for DSE. Would this be an acceptable solution? Jake On Mon, Feb 20, 2023 at 11:17 AM guo Maxwell wrote: > It seems “An alternative solution is to

Re: Downgradability

It seems “An alternative solution is to implement/complete CASSANDRA-8110 ” can give us more options if it is finished Branimir Lambov 于2023年2月20日 周一下午11:03写道： > Hi everyone, > > There has been a discussion lately about changes to the

Downgradability

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.

downgrade sstables

I have been working on downgrading sstables for awhile now. I have the downgrader mostly working. The only issue is when downgrading system tables. Specifically during the 3.1 -> 4.0 changes a column broadcast_port was added to system/local. This means that 3.1 system can not read the table as

Re: [jira] [Commented] (CASSANDRA-17698) sstabledump errors when dumping data from index

for old version‘s index data using this version’s dump code ，I think there will not be much difference（may be only exception message‘s difference），It is backwards compactibility I think .But I change the content of sstable（adding a new base type for partitionordertype）. Benedict Elliott Smith