cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Lohfink (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-14291) Nodetool command to recreate SSTable components
Date Wed, 18 Jul 2018 18:40:00 GMT


Chris Lohfink commented on CASSANDRA-14291:

Seems a little scary to be deleting and recreating components on an active sstable, but the
bf and summary are not directly read from except from tooling so it looks safe to me.

Since others are same as just doing an upgradesstables there seems to be a lot of overlap
with that command. Since that command doesnt have much right now (just -a) it doesnt seem
to me like it would bloat to much to add a -c or --components to it. Maybe naming gets confusing
and a "rebuildsstables" command is really what we want but I wont argue the semantics.

I dont see anything that recreates the bloom filter with current settings, just reserializing
whats already in memory.

> Nodetool command to recreate SSTable components
> -----------------------------------------------
>                 Key: CASSANDRA-14291
>                 URL:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message