You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Brad Schoening (Jira)" <ji...@apache.org> on 2026/06/25 02:41:00 UTC
[jira] [Updated] (CASSANDRA-21331) Improve Incremental Repair documentation clarity
[ https://issues.apache.org/jira/browse/CASSANDRA-21331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brad Schoening updated CASSANDRA-21331:
---------------------------------------
Test and Documentation Plan: Doc only change
Status: Patch Available (was: Open)
> Improve Incremental Repair documentation clarity
> ------------------------------------------------
>
> Key: CASSANDRA-21331
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21331
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Documentation
> Reporter: Brad Schoening
> Assignee: Doyeon Kim
> Priority: Low
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The [Incremental Repair |https://cassandra.apache.org/doc/5.0.8/cassandra/managing/operating/auto_repair.html#incremental-repair] documentation has several clarity and usability issues:
> * *Missing context on anticompaction impact:* The docs mention that repair can _overwhelm a cluster with anticompactions_ but don't explain the underlying mechanism — specifically, what about the repair process triggers them.
> * *Poor navigation to anticompaction reference:* The link to {{compaction/overview.html#types-of-compaction}} lands on an unordered list of 9 compaction types, requiring users to scroll to the 8th entry. Either add a direct anchor ({{{}#anticompaction{}}}) or alphabetize the list.
> * *Unexplained initial incremental vs. full repair behavior:* It's unclear why an initial incremental repair (which must repair all data) would differ from a full repair. The distinction needs explanation.
> {quote}Enabling Incremental Repair on existing clusters with a large amount of data
> {quote}
> {quote}One should be careful when enabling incremental repair on a cluster for the first time. While RepairTokenRangeSplitter includes a default configuration to attempt to gracefully migrate to incremental repair over time, failure to take proper precaution could overwhelm the cluster with anticompactions.
> {quote}
> {quote}No matter how one goes about enabling and running incremental repair, it is recommended to run a cycle of full repairs for the entire cluster as pre-flight step to running incremental repair. This will put the cluster into a more consistent state which will reduce the amount of streaming between replicas when incremental repair initially runs.
> {quote}
> {quote}[https://cassandra.apache.org/doc/5.0.8/cassandra/managing/operating/auto_repair.html#incremental-repair]
> {quote}
>
--
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