Change repair strategies

Set the method used for routine repairs to incremental or full repair.

Repairing SSTables using anti-entropy repair is required for database maintenance.

A full repair of all SSTables on a node is long running and resource intensive. Incremental repair consumes less time and resources because it skips SSTables that are already marked as repaired. However, incremental repairs aren’t recommended for all use cases.

Migrate to full repairs

The incremental repair strategy splits the data into repaired and unrepaired SSTables, and it marks the data state with metadata. In contrast, the full repair strategy keeps the data together and uses no repair status flag.

  1. Before switching from incremental repairs to full repairs, remove the repaired status flag that isn’t used for full repairs:

    nodetool mark_unrepaired KEYSPACE_NAME TABLE_NAME

    Table name is optional. If omitted, the repaired flag is removed from all tables in the specified keyspace.

    For tarball installations, run this command from the /bin directory of your HCD installation.

  2. Get a list of the SSTable data files located in /var/lib/cassandra/data.

    You need this list to run the command to set the repairedAt flag later in this process when you mark the tables as repaired.

  3. Run the default full, sequential repair on one node at a time.

    Running nodetool repair without parameters runs a full sequential repair of all SSTables on the node and can take a substantial amount of time:

    nodetool repair

Migrate to incremental repairs

DataStax recommends using full repairs in HCD 1.2 because incremental repairs can cause performance issues. If you choose to use incremental repairs, migrate clusters to incremental repair one node at a time for data integrity and minimal performance impact.

DataStax recommends that you migrate clusters to incremental repairs node-by-node for the following reasons:

  • The first system-wide repair across all nodes can be long running because the database must recompact all SSTables. Migrating node-by-node isolates recompaction to individual nodes.

  • Because incremental repair skips SSTables that are already marked as repaired, the migration process ensures data integrity when changing the repair strategy from full to incremental.

Use these steps to migrate the SSTables on each node to the incremental repair strategy:

  1. Disable autocompaction on the node.

    Running nodetool disableautocompaction without parameters disables autocompaction for all keyspaces:

    nodetool disableautocompaction

    For tarball installations, run this command from the /bin directory of your HCD installation.

  2. Before running a full repair in the next step, get a list of the SSTable data files in /var/lib/cassandra/data.

    You need this list to run the command to set the repairedAt flag later in this process when you mark the tables as repaired.

  3. Run the default full, sequential repair on one node at a time.

    Running nodetool repair without parameters runs a full sequential repair of all SSTables on the node and can take a substantial amount of time:

    nodetool repair
  4. Stop the node.

  5. Using the list you created earlier in this process, set the repairedAt flag on each SSTable with sstablerepairedset and the --is-repaired option.

    If you don’t set repairedAt to --is-repaired for each SSTable, the existing SSTables might not be changed by the repair process, and any incremental repair processes that run later won’t process these SSTables.

    To mark a single SSTable as repaired, run the following command, replacing SSTABLE_NAME_DATA_FILE_NAME with the actual SSTable data file name:

    sudo sstablerepairedset --really-set --is-repaired SSTABLE_DATA_FILE_NAME

    For batch processing of multiple SSTables, provide a text file containing SSTable data file names:

    sudo sstablerepairedset --really-set --is-repaired -f SSTable-names.txt

    For tarball installations, run these commands from the /resources/cassandra/tools/bin directory of your HCD installation.

    The value of the repairedAt flag is the timestamp of the last repair. The sstablerepairedset command sets the timestamp to the current date/time when you run the command. To check the value of the repairedAt flag, use sstablemetadata:

    sstablemetadata KEYSPACE_NAME-SSTABLE_DATA_FILE_NAME | grep "Repaired at"
  6. Restart the node.

  7. After you have migrated all nodes, you can run incremental repairs as needed using nodetool repair with the -inc option.

Was this helpful?

Give Feedback

How can we improve the documentation?

© Copyright IBM Corporation 2026 | Privacy policy | Terms of use Manage Privacy Choices

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: Contact IBM