Subrange incremental repair

[adejanovski]

Fixes #1502

Before reviewing, please ensure you're aware of our PR review guidelines.

Here are the key changes in this PR:

Dependency Update

• pom.xml:
  • The Checkstyle version is updated from 8.19 to 10.17.0. This might include enhancements, bug fixes, or new features provided by the newer Checkstyle version.

New Configuration Options for Incremental Repair

• api.md:

  • The incrementalRepair option is expanded to clarify that it performs incremental repair on all tokens of each node at once.
  • A new option subrangeIncrementalRepair is introduced. This allows incremental repair to be done in subrange mode, targeting discrete token ranges. This option is available starting from Cassandra 4.0.

• docker_vars.md and reaper_specific.md:

  • Added REAPER_SUBRANGE_INCREMENTAL environment variable to support subrange incremental repairs.
  • Documentation updates to explain the purpose and usage of the subrangeIncrementalRepair setting.

Configuration Changes

• Dockerfile and Environment Variables:
  • Environment variable REAPER_SUBRANGE_INCREMENTAL is set to false by default in Docker configurations, allowing users to enable it as needed.

Checkstyle Configuration Update

• checkstyle.xml:
  • Updated to the new Checkstyle DTD to https://checkstyle.org/dtds/configuration_1_3.dtd.
  • Some reorganization and cleanup in the Checkstyle configuration for better readability and alignment with the new Checkstyle version.

CLI Enhancements

• spreaper:
  • Added a new argument --subrange-incremental to the CLI tool, allowing users to specify whether to perform subrange incremental repairs directly from the command line.

Code Adjustments for Repair Functionality

• ReaperApplication.java:

  • Added logging for the new subrangeIncrementalRepair configuration to ensure it is correctly read and applied.

• AppContext.java and ClusterFacade.java:

  • Adjusted the classes to include support for subrange incremental repairs.

• RepairUnit.java:

  • Updated to include a new boolean field subrangeIncrementalRepair.
  • Adjusted constructor and builder pattern to accommodate the new field.

• RepairRunService.java, RepairManager.java, RepairRunner.java, and SegmentRunner.java:

  • Various methods updated to handle subrange incremental repairs. This includes segment generation, segment repair initiation, and leader election for repair segments.
  • Subrange incremental repair segments are treated differently from regular incremental repair segments, ensuring proper handling and preventing overlapping repairs.

• RepairType.java:

  • A new enum to clearly define and distinguish between different repair types: SUBRANGE_FULL, INCREMENTAL, and SUBRANGE_INCREMENTAL.

Database Interaction

• RepairUnitService.java:
  • Added checks to ensure subrangeIncrementalRepair is only enabled for Cassandra versions 4.0 and above.
  • Validation added to prevent enabling both incrementalRepair and subrangeIncrementalRepair in incompatible versions of Cassandra.

Miscellaneous Adjustments

• RepairRunResource.java and RepairScheduleResource.java:
  • Updated to accept and validate the new subrangeIncrementalRepair parameter.
  • Ensured compatibility and correct application of the new setting during repair run and schedule creation.

By introducing subrangeIncrementalRepair, this PR enhances the repair flexibility for large clusters, particularly those running on Cassandra 4.0 or later. This mode allows for more efficient repairs by dividing the repair process into smaller, manageable subranges, potentially improving performance and reducing repair time.

[michaelsembwever]

ton of work here, lgtm, just some comments wrt readability and safety.

what does concern me is if this addresses the primary reason (as far as we know) to want to use subrange IR – to break up and pace out the IR+anti-compactions to a rate and load that stabilises the cluster…

how do we know subranges are optimal for this ?

[adejanovski]

what does concern me is if this addresses the primary reason (as far as we know) to want to use subrange IR – to break up and pace out the IR+anti-compactions to a rate and load that stabilises the cluster… how do we know subranges are optimal for this ?

We don't, and I guess it depends on factors that we don't control. Since this has been requested and is allowed by Cassandra 4, I think it's ok to give the option and let users find the best solution for their clusters. The good part here is that the number of segments is tunable, so one can find a sweet spot even with large numbers of vnodes.

[adejanovski]

Comments addressed, ready for another review @michaelsembwever