[jira] [Commented] (CASSANDRA-14291) Nodetool command to recreate SSTable components

["Alexander Ivakov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-14291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16539519#comment-16539519 ] 

Alexander Ivakov commented on CASSANDRA-14291:
----------------------------------------------

Rebuilding some of the components (eg. primary index) requires going through all the data in the SSTable, so this is basically similar to a compaction. It is proposed, for the sake of simplicity, to implement this command to call upgradesstables in the background if recreating any of these components:
primary index, compression info, secondary index, stats.

Note: this will recreate all components and also re-write the data file out to disk.

Recreating the bloom filter and the index summary (using the saved primary index) can be done without going through the whole data, so these can be done separately and without re-writing data and all other components.

> Nodetool command to recreate SSTable components
> -----------------------------------------------
>
>                 Key: CASSANDRA-14291
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14291
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Kurt Greaves
>            Assignee: Alexander Ivakov
>            Priority: Minor
>
> Need a JMX/Nodetool command to recreate components for SSTables without re-writing the data files.
> Possible implementation idea:
> Create a {{nodetool (recreate|regen)component}} command that would enable you to recreate  specific components of an SSTable, and also allow specifying SSTables or columnfamilies.
> I'd say a flag for a list of components and a flag for SSTables with keyspace.columnfamilies as positional arguments would work
> Alternatively this could become part of upgradesstables, but would likely make that command a bit bloated.
> Background:
> In CASSANDRA-11163 we changed it so summaries and bloomfilters were not regenerated or persisted on startup. This means we would rely on compactions/upgrades to regenerate the bloomfilter (or other components) after a configuration change. While this works, it's pretty inefficient on large tables just because you changed the bloomfilter size or summary chunk sizes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org