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

Brandon Williams commented on CASSANDRA-14291:
----------------------------------------------

bq. Seems a little scary to be deleting and recreating components on an active 
sstable

Is there any reason this shouldn't be done in an offline manner, since the user 
can then examine the results and decide to make them live (via refresh) later 
if they choose? I have seen more cases of "I lost component X and now I have to 
throw the entire sstable away even though it could be regenerated" than 
instances of wanting to regenerate existing components in place.

> Nodetool command to recreate SSTable components
> -----------------------------------------------
>
>                 Key: CASSANDRA-14291
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14291
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tool/nodetool
>            Reporter: Kurt Greaves
>            Assignee: Alexander Ivakov
>            Priority: Low
>              Labels: 4.0-feature-freeze-review-requested
>
> 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
(v8.3.4#803005)

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

Reply via email to