Changing repair strategies
Change the method used for routine repairs from incremental or full repair. Repairing SSTables using anti-entropy repair is required for database maintenance. A full repair of all SSTables on a node takes a lot of time and is resource-intensive. Incremental repair consumes less time and resources because it skips SSTables that are already marked as repaired.
Migrating to full repairs
Incremental repairs split the data into repaired and unrepaired SSTables and mark the data state with metadata. Full repairs keeps the data together and uses no repair status flag. Before switching from incremental repairs to full repairs remove the status.
nodetool mark_unrepaired keyspace_name [table_name]
Migrating to incremental repairs
To start using incremental repairs, migrate the SSTables on each node.
About this task
To start using incremental repairs, migrate the SSTables on each node. Incremental repair skips SSTables that are already marked as repaired. These steps ensure the data integrity when changing the repair strategy from full to incremental.
DataStax recommends using full repairs. Incremental repairs may cause performance issues. See CASSANDRA-9143. |
Prerequisites
In RHEL and Debian installations, you must install the tools packages before following these steps.
Before starting this procedure, be aware that the first system-wide full repair (step 3) can take a long time, as the database recompacts all SSTables. To make this process less disruptive, migrate the cluster to incremental repair one node at a time. |
Procedure
-
In a terminal:
-
Disable autocompaction on the node:
nodetool disableautocompaction
Tarball and Installer No-Services path:install_directory/bin
Running
nodetool disableautocompaction
without parameters disables autocompaction for all keyspaces. -
Before running a full repair (3), list the nodes SSTables located in
/var/lib/cassandra/data
. You need this list to run the command to set therepairedAt
flag in 5.The data directory contains a subdirectory for each keyspace. Each subdirectory contains a set of files for each SSTable. The name of the file that contains the SSTable data has the following format:
<version_code>-<generation>-<format>-Data.db
-
Run the default full, sequential repair on one node at a time:
nodetool repair
Tarball and Installer No-Services path:
<install_directory>/bin
Running
nodetool repair
without parameters runs a full sequential repair of all SSTables on the node and can take a substantial amount of time. -
Using the list you created in 2, set the
repairedAt
flag on each SSTable usingsstablerepairedset
to--is-repaired
.Unless you set the
repairedAt
to repaired for each SSTable, the existing SSTables might not be changed by the repair process and any incremental repair process that runs later will not process these SSTables.-
To mark a single SSTable:
sudo sstablerepairedset --really-set --is-repaired SSTable-example-Data.db
-
For batch processing, use a text file of SSTable names:
sudo sstablerepairedset --really-set --is-repaired -f SSTable-names.txt
Tarball and Installer No-Services path:
installation_location/resources/cassandra/tools/bin
The value of the
repairedAt
flag is the timestamp of the last repair. Thesstablerepairedset
command applies the current date/time. To check the value of therepairedAt
flag, use:sstablemetadata example-keyspace-SSTable-example-Data.db | grep "Repaired at"
-
Next steps
After you have migrated all nodes, you can run incremental repairs using nodetool repair
with the -inc
option.
Related information