bschoening commented on code in PR #4881: URL: https://github.com/apache/cassandra/pull/4881#discussion_r3526435011
########## doc/modules/cassandra/pages/managing/operating/auto_repair.adoc: ########## @@ -64,10 +64,16 @@ a smaller set of data, so a shorter `min_repair_interval` such as `1h` is recomm One should be careful when enabling incremental repair on a cluster for the first time. While xref:#repair-token-range-splitter[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 -xref:managing/operating/compaction/overview.adoc#types-of-compaction[anticompactions]. +xref:managing/operating/compaction/overview.adoc#anticompaction[anticompactions]. + +This happens because incremental repair must separate the ranges participating in repair from the rest of the Review Comment: This happens because incremental repair must keep repaired and un-repaired data in separate SSTables. It uses anti-compaction to split the affected SSTables, separating the data covered by the repair session from the data left untouched. On clusters with large SSTables or high partition overlap, rewriting these files can generate substantial disk I/O and overhead. From the operator's perspective, a repair runs against a whole table. Internally, however, Cassandra decomposes that repair into sessions, each covering a portion of the cluster's token space. A single SSTable interleaves rows from many token ranges, so any given file typically contains a mix of data the session repaired and data it never looked at. Cassandra therefore cannot simply mark the whole SSTable as repaired. Instead it uses xref:managing/operating/compaction/overview.adoc#anticompaction[anticompaction] to rewrite each participating SSTable into two: one containing the data covered by the repair session (marked repaired), and one containing everything else (which remains unrepaired). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
