[
https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656006#comment-17656006
]
Stefan Miklosovic edited comment on CASSANDRA-18061 at 1/9/23 12:05 PM:
------------------------------------------------------------------------
[~maxwellguo] ,
the problem I see with that failing test I mentioned in my last reply is that
we are trying to upgrade from 4.0 to 4.2 and it fails. What you did is that you
changed it in such a way that you are upgrading from 4.1. I do not think this
is the fix.
I believe we have to be able to upgrade straight from 4.0 to 4.2 (or to 5.0 if
4.2 will be eventually called like that).
The reason that test fails is that after upgrade, 4.x node tries to read /
write to system.compaction_history table from / to column called
"compaction_type" but schemas from 4.0 do not have that column yet.
There is this class (1) which _migrates_ system schemas from older to newer
schema (whatever that means) by creating _v2 tables and copying all data there
(and optionally modifying it).
I think that we should do something similar here so we would have a table
called "system.compaction_history_v2" with this new column and all interaction
would be done with it.
However, I am not completely sure if we want to introduce new
compaction_history_v2 table into system keyspace just to be able to see
compaction types.
I am summoning the heavyweights to know their opinion on this:
[~brandon.williams] [~mck]. Am I correct we need to support 4.0 -> 5.0 upgrade
so we need to migrate compaction_history to a new table?
I am not completely sure what "to upgrade" means in this context.
EDIT: I see that system.compaction_history is present in 3.0 already so if
somebody upgrades from 3.0 to 4.2, he will hit that issue.
On the other hand, it does not migrate _all_ tables so it seems to me like it
counts on the fact that system keyspace is completely wiped out prior upgrade
except the tables it specifically migrates? So in that case we should be safe
to have a test which upgrades just from 4.1 up?
Thanks
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SystemKeyspaceMigrator41.java]
was (Author: smiklosovic):
[~maxwellguo] ,
the problem I see with that failing test I mentioned in my last reply is that
we are trying to upgrade from 4.0 to 4.2 and it fails. What you did is that you
changed it in such a way that you are upgrading from 4.1. I do not think this
is the fix.
I believe we have to be able to upgrade straight from 4.0 to 4.2 (or to 5.0 if
4.2 will be eventually called like that).
The reason that test fails is that after upgrade, 4.x node tries to read /
write to system.compaction_history table from / to column called
"compaction_type" but schemas from 4.0 do not have that column yet.
There is this class (1) which _migrates_ system schemas from older to newer
schema (whatever that means) by creating _v2 tables and copying all data there
(and optionally modifying it).
I think that we should do something similar here so we would have a table
called "system.compaction_history_v2" with this new column and all interaction
would be done with it.
However, I am not completely sure if we want to introduce new
compaction_history_v2 table into system keyspace just to be able to see
compaction types.
I am summoning the heavyweights to know their opinion on this:
[~brandon.williams] [~mck]. Am I correct we need to support 4.0 -> 5.0 upgrade
so we need to migrate compaction_history to a new table?
I am not completely sure what "to upgrade" means in this context.
Thanks
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SystemKeyspaceMigrator41.java]
> Add compaction type output result for nodetool compactionhistory
> ----------------------------------------------------------------
>
> Key: CASSANDRA-18061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18061
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction, Tool/nodetool
> Reporter: maxwellguo
> Assignee: maxwellguo
> Priority: Low
> Fix For: 4.x
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> If we want to see whether we have made a compaction and what kind of
> compaction we have done for this node, we may go to see the
> compaction_history system table for some deftails or use nodetool
> compactionhistory command , But I found that the table do not specify the
> compaction type so does the compactionhistory command too, like index build ,
> compaction type, clean or scrub for this node. So I think may be it is need
> to add a type of compaction column to specify the compaction tpe for
> system.compaction_history and so we can get the type of compaction through
> system.compaction_history table or nodetool compactionhistory to see whether
> we have made a major compact for this node .:)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
