[
https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723930#comment-17723930
]
Claude Warren edited comment on CASSANDRA-8928 at 5/18/23 2:52 PM:
-------------------------------------------------------------------
[~nasnousssi]
I have updated the pull request: [https://github.com/apache/cassandra/pull/2045]
The problem has been that between v3 and v4 there was a breaking change in the
system local table where the columns "broadcast_port", "listen_port", and
"rpc_port" were added. The code (in the current pull request) provides
functionality to remove those columns when the older table is written. The
code also allows for other transformations of the columns, though none are
implemented.
In order for the downgrade to work the following steps are taken (not all are
in this code, some are in a script I have for testing the process)
# Execute the standalone downgrade on the desired table(s).
# Delete the system_schema tables.
# Delete the {*}-Filter.db, *-Index.db, *-TOC.txt, *-Digest.{*}, and
*-Summary.db for the modified table(s)
# Delete the original files (e.g. nb-*)
# Start the earlier version of the software.
I tested the current code by starting 4.1 to create the tables. Downgraded all
the tables in the database to "ma" version, followed the above steps and
started 3.11 According to the logs 3.11.14 started.
The current pull request code is not as clean as I would like it, but it does
work correctly.
I would like some comments on the general approach for removing columns where
they are filtered out of the row definition during writing.
was (Author: claudenw):
I have updated the pull request: [https://github.com/apache/cassandra/pull/2045]
The problem has been that between v3 and v4 there was a breaking change in the
system local table where the columns "broadcast_port", "listen_port", and
"rpc_port" were added. The code (in the current pull request) provides
functionality to remove those columns when the older table is written. The
code also allows for other transformations of the columns, though none are
implemented.
In order for the downgrade to work the following steps are taken (not all are
in this code, some are in a script I have for testing the process)
# Execute the standalone downgrade on the desired table(s).
# Delete the system_schema tables.
# Delete the *-Filter.db, *-Index.db, *-TOC.txt, *-Digest.*, and *-Summary.db
for the modified table(s)
# Delete the original files (e.g. nb-*)
# Start the earlier version of the software.
I tested the current code by starting 4.1 to create the tables. Downgraded all
the tables in the database to "ma" version, followed the above steps and
started 3.11 According to the logs 3.11.14 started.
The current pull request code is not as clean as I would like it, but it does
work correctly.
I would like some comments on the general approach for removing columns where
they are filtered out of the row definition during writing.
> Add downgradesstables
> ---------------------
>
> Key: CASSANDRA-8928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8928
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Tools
> Reporter: Jeremy Hanna
> Assignee: Claude Warren
> Priority: Low
> Labels: remove-reopen
> Fix For: 5.x
>
>
> As mentioned in other places such as CASSANDRA-8047 and in the wild,
> sometimes you need to go back. A downgrade sstables utility would be nice
> for a lot of reasons and I don't know that supporting going back to the
> previous major version format would be too much code since we already support
> reading the previous version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
