[
https://issues.apache.org/jira/browse/CASSANDRA-20118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17903375#comment-17903375
]
Stefan Miklosovic edited comment on CASSANDRA-20118 at 12/5/24 1:27 PM:
------------------------------------------------------------------------
We have SystemKeyspaceMigrator41 in 5.0 and similarly SystemKeyspaceMigrator40
in 4.1. So on upgrade, when that code is run, we migrate rows from "old tables"
to "new table". I am not sure if that itself changes the schema version
specifically between 4.1 and 5.0 but it is worth to say that for 5.0 branch,
the only column we add is system.compaction_history where we are adding
compaction_properties column. All other migrations work in such a way that we
are taking the content of one table and we are populating another table. But
for compaction_properties case, we just go to transform the table itself,
putting null into that column.
But, even if we introduced a completely new table for compaction_history (e.g.
compaction_history_v2) and we did a migration in such a way that we would take
what is in compaction_history and populated compaction_history_v2 with it, that
would change the schema version as well, wouldn't it? Because we just
introduced a completely new table, _v2. Basically, every time we introduce a
new schema change in system keyspaces in a new version, the schema would be
different just because of that ...
(1)
https://github.com/apache/cassandra/commit/49dfb805e9045c856181d6c2ac3b586b98d1a82a#diff-348b3326d0092817e79777685a9110448b8e8ea78e88fc05705a56d041230bf7R179
was (Author: smiklosovic):
We have SystemKeyspaceMigrator41 in 5.0 and similarly SystemKeyspaceMigrator40
in 4.1. So on upgrade, when that code is run, we migrate rows from "old tables"
to "new table". I am not sure if that itself changes the schema version
specifically between 4.1 and 5.0 but it is worth to say that for 5.0 branch,
the only column we add is system.compaction_history where we are adding
compaction_properties column. All other migrations work in such a way that we
are taking the content of one table and we are populating another table. But
for compaction_properties case, we just go to transform the table itself,
putting null into that column.
But, even if we introduced a completely new table for compaction_history (e.g.
compaction_history_v2) and we did a migration in such a way that we would take
what is in compaction_history and populated compaction_history_v2 with it, that
would change the schema version as well, wouldn't it? Because we just
introduced a completely new table, _v2. Basically, every time we introduce a
new schema change in system keyspaces in a new version, the schema would be
different just because of that ...
(1)
https://github.com/apache/cassandra/commit/49dfb805e9045c856181d6c2ac3b586b98d1a82a#diff-348b3326d0092817e79777685a9110448b8e8ea78e88fc05705a56d041230bf7R176
> Hints ignored during Upgrade from C*4 to C*5
> --------------------------------------------
>
> Key: CASSANDRA-20118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20118
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
> Reporter: Paul Chandler
> Priority: Normal
> Fix For: 5.0.x
>
>
> I have discovered that some hints were not being processed after nodes come
> back up when a cluster in in a mixed mode with some cassandra 4 nodes and
> some cassdandra 5 nodes ( these with a storage compatibility mode CASSANDRA_4
> )
>
> When in this mode there is a schema mismatch after the first node has been
> upgraded, which continues until the last node has been upgraded.
> It seems that the hints are blocked from being sent if there is a schema
> mismatch between the 2 nodes, that can be seen at this line.
> [cassandra/src/java/org/apache/cassandra/hints/HintsDispatchTrigger.java at
> cassandra-5.0 ·
> apache/cassandra|https://github.com/apache/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/hints/HintsDispatchTrigger.java#L65]
> I have tested removing this line, and that then does allow the hint to be
> transferred normally. However I am not sure of the implications for doing
> that if the hint is for part of the schema where the actual mismatch occurs.
>
> This creates the problem when a node is being upgraded and is currently down,
> hint files will be created for it on the new cassandra 5 nodes and the old
> cassandra 4 nodes, but the hint files on the old cassandra 4 nodes will not
> be processed, due to the schema mismatch. Leading to potential data loss.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
