You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Dmitry Konstantinov (Jira)" <ji...@apache.org> on 2025/01/12 13:43:00 UTC

[jira] [Created] (CASSANDRA-20197) Provide the ability to reset Repaired At metadata without Cassandra node shutdown

Dmitry Konstantinov created CASSANDRA-20197:
-----------------------------------------------

             Summary: Provide the ability to reset Repaired At metadata without Cassandra node shutdown
                 Key: CASSANDRA-20197
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-20197
             Project: Apache Cassandra
          Issue Type: Improvement
          Components: Consistency/Repair
            Reporter: Dmitry Konstantinov


Background: It is a quite frequent issue when by mistake for a Cassandra cluster and incremental repair is triggered instead of a full one (incremental as a default option helps with it). As a result we have SSTable marked within non-zero "Repaired At" value and the are separated by compaction logic to a separate SSTable pool. If incremental repair is not executed regularly after it we have issues like uncleaned tombstones sitting forever within the table even after a major compaction.

The current way to solve the issue is to use [sstablerepairedset|https://cassandra.apache.org/doc/stable/cassandra/tools/sstable/sstablerepairedset.html] command but we have to stop Cassandra node to run it, so to recover from the issue described before we have to do a rolling restart of Cassandra nodes - it is time consuming and affects performance due to a warmup period after a restart.

The improvement is about introducing an nodetool command which can ask Cassandra node to reset "Repaired At" value for local SSTables of a table in runtime without an node shutdown.

A command can look like:
{code:java}
nodetool set-unrepaired some_keyspace.some_table
nodetool set-unrepaired some_keyspace{code}
 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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