[
https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656102#comment-17656102
]
maxwellguo edited comment on CASSANDRA-18061 at 1/9/23 1:22 PM:
----------------------------------------------------------------
v40 and v41 are all ok , I add both of them now, both 40 and 41 to upgrade to
42 will be test ,and the jvm-dtest seems green now.
pr : https://github.com/apache/cassandra/pull/2047/commits
java8 precommit :
https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/361/workflows/ff85f81b-6100-43fa-b897-75a6ee17fd5e
For me I think we do not need a compaction_history_v2 for the compaction_type
is a newly added column and when people upgrade from lower version to some
version that added the compaction_type existed syystem table , the column data
is null and an UN_KNOW flag will return if the column added is finally used。
I have check the table described in
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SystemKeyspaceMigrator41.java
It seems that all of the schema (primary key or column name) have changed . So
if upgrade from lower version I think the data must be migrated. for
LEGACY_PEERS/PEER_EVENTS_V2/TABLE_ESTIMATES/SSTABLE_ACTIVITY_V2 primary key is
changed. FOR AVAILABLE_RANGES_V2 column name is changed.
But compaction_type is only a newly added column and the primary key nor
cluster name is not change. The original data can be read , and
The new compaction_type column that have no data will return UN_KNOW(I have
just test in my own cluster.)
Besides for system schema PAXOS_REPAIR_HISTORY I saw it is add in Cassandra-4.1
but none SystemKeyspaceMigrator41 is needed
and for [CASSANDRA-10857|https://issues.apache.org/jira/browse/CASSANDRA-10857]
a new column "value" is also added for "IndexInfo" system table [code line 142
SystemKeyspace.java
|https://github.com/apache/cassandra/commit/07fbd8ee6042797aaade90357d625ba9d79c31e0#diff-f57518f964c71328146aeca95be5e697ca81a77261719eeef4dd4b1ed8daf63bR142]
and none SystemKeyspaceMigrator41 is needed too, patched by [~ifesdjeen]
So it seem no SystemKeyspaceMigrator41 is needed for a newly added column .
Also I think this is a little patch , and tt doesn't even matter.So I am ok if
we just set the Status to "wan't fix" :)
was (Author: maxwellguo):
v40 and v41 are all ok , I add both of them now.
java8 precommit :
https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/361/workflows/ff85f81b-6100-43fa-b897-75a6ee17fd5e
For me I think we do not need a compaction_history_v2 for the compaction_type
is a newly added column and when people upgrade from lower version to some
version that added the compaction_type existed syystem table , the column data
is null and an UN_KNOW flag will return if the column added is finally used。
I have check the table described in
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SystemKeyspaceMigrator41.java
It seems that all of the schema (primary key or column name) have changed . So
if upgrade from lower version I think the data must be migrated. for
LEGACY_PEERS/PEER_EVENTS_V2/TABLE_ESTIMATES/SSTABLE_ACTIVITY_V2 primary key is
changed. FOR AVAILABLE_RANGES_V2 column name is changed.
But compaction_type is only a newly added column and the primary key nor
cluster name is not change. The original data can be read , and
The new compaction_type column that have no data will return UN_KNOW(I have
just test in my own cluster.)
Besides for system schema PAXOS_REPAIR_HISTORY I saw it is add in Cassandra-4.1
but none SystemKeyspaceMigrator41 is needed
and for [CASSANDRA-10857|https://issues.apache.org/jira/browse/CASSANDRA-10857]
a new column "value" is also added for "IndexInfo" system table [code line 142
SystemKeyspace.java
|https://github.com/apache/cassandra/commit/07fbd8ee6042797aaade90357d625ba9d79c31e0#diff-f57518f964c71328146aeca95be5e697ca81a77261719eeef4dd4b1ed8daf63bR142]
and none SystemKeyspaceMigrator41 is needed too, patched by [~ifesdjeen]
So it seem no SystemKeyspaceMigrator41 is needed for a newly added column .
Also I think this is a little patch , and tt doesn't even matter.So I am ok if
we just set the Status to "wan't fix" :)
> 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: [email protected]
For additional commands, e-mail: [email protected]
