Segment count value in repair status not correct for subrange repair about cassandra-reaper HOT 8 CLOSED

HI,

this is deliberate actually.

Incremental repair doesn't handle concurrency very well, and it definitely does not work with subrange repair (anticompaction is disactivated in Cassandra with subrange repair).

And if you try to run it on more than one node at a time, you'll get in Validation Error hell, because an SSTable cannot be validation compacted and anticompacted at the same time.

I forced Reaper to create a single "fake" segment per node, so that we only process one node at a time.

If you want to perform subrange repair just set incremental to false (which you should do unless you're using TWCS, which might be the only compaction strategy that could work correctly with incremental repair).

from cassandra-reaper.

Yes, but nodes.keySet().size() can be passed only in case when incremental repair is true. If incremental repair is false, that means that subrange repair is run and tokenSegments.size() should be passed as argument, right?

from cassandra-reaper.

Hi @milannister ,

the number of segments will get overriden in storeNewRepairSegment() :

private static void storeNewRepairSegments(AppContext context, List<RingRange> tokenSegments,
                                             RepairRun repairRun, RepairUnit repairUnit) {
    List<RepairSegment.Builder> repairSegmentBuilders = Lists.newArrayList();
    for (RingRange range : tokenSegments) {
      RepairSegment.Builder repairSegment = new RepairSegment.Builder(repairRun.getId(), range,
                                                                      repairUnit.getId());
      repairSegmentBuilders.add(repairSegment);
    }
    context.storage.addRepairSegments(repairSegmentBuilders, repairRun.getId());
    if (repairRun.getSegmentCount() != tokenSegments.size()) {
      LOG.debug("created segment amount differs from expected default {} != {}",
                repairRun.getSegmentCount(), tokenSegments.size());
      context.storage.updateRepairRun(
          repairRun.with().segmentCount(tokenSegments.size()).build(repairRun.getId()));
    }
  }

Here you can see that we call udpateRepairRun and feed it with tokenSegments.size().

from cassandra-reaper.

Hi @adejanovski

You are right. It appears that the value is overwritten.

However, based on the schedule:

I would expect that segment count on repair result screen is not equal to the number of nodes (which is 20 in our case), but to the value on schedule screen:

Why is this happening?

from cassandra-reaper.

Hi @milannister,

I can reproduce the bug locally and will issue a fix ASAP.

from cassandra-reaper.

@milannister,

fix has been merged into master.
The display wasn't right but the number of segments was correct.

Please confirm that the fix works for you.

Thanks

from cassandra-reaper.

Fix released in 0.5.0

from cassandra-reaper.

Sorry for late response. We are currently testing the cluster without repair. Will confirm the fix locally as soon as I setup the environment.
Thanks for being so responsive!

from cassandra-reaper.