Reaper increases its default repair segmentation

A repair timeout can reflect the size of the work assigned to a segment. Reaper 2.0.5 responds by increasing its default segment count per node from 16 to 64. The intent is to avoid timeouts in most cases by dividing a repair more finely. The release also brings its Docker configuration into line with the per-node setting, which changes the meaning of the number operators supply.

The June 19 release names this default change as its first item. Alexander Dejanovski implemented it in the configuration patch, which changes the Java default and the packaged configuration examples together. That agreement matters because the effective default can otherwise depend on which installation method supplied the configuration file.

I regard repair as part of the cost of choosing Cassandra for active-active operation at scale. A default that gives the repair service smaller units to manage is therefore worth understanding. Its effect comes from the amount of token space assigned to each unit, and it should not be confused with an increase in database capacity.

A per-node count is a scaling rule

Reaper documents segmentCountPerNode as the default number of repair segments created for each node when registering a new repair run. Each segment is repaired separately until the token ring has been covered. The versioned configuration documentation gives a ten-node example with twenty segments per node, producing approximately two hundred token subranges.

Applying the same arithmetic to the new default gives a target of approximately six hundred and forty segments for a ten-node cluster. That figure is an illustration of the configuration rule, not a guarantee about the exact generated count. The documentation explains that small token ranges and the organisation of a cluster across datacenters can add segments beyond the requested count.

The segment generator makes the approximation concrete. Its contract says the requested total is a minimum and that generation can produce more segments. In the subdivision path, it calculates how much of the token ring a range occupies and rounds the corresponding segment allocation upward. Rounding at range boundaries can therefore affect the total.

This is division of token space. Equal intervals of token space do not, by that fact alone, establish equal elapsed repair times. The generator accepts token ranges as its input, and its calculation uses their widths. No measured throughput figure appears in the default-change patch, so the increase should not be presented as a quantified speed improvement.

The Docker change also changes units

Previously, the Dockerfile set REAPER_SEGMENT_COUNT to 200. Its configuration template mapped that variable to segmentCount. The patch replaces it with REAPER_SEGMENT_COUNT_PER_NODE, sets its default to 64 and maps it to segmentCountPerNode. The new environment variable therefore expresses a different configuration concept.

The configuration file expresses the count with segmentCountPerNode. The packaged examples now supply the following value.

segmentCountPerNode: 64

The Docker template obtains that setting through its environment. The corresponding assignment uses the new variable name.

REAPER_SEGMENT_COUNT_PER_NODE=64

The old number 200 should not simply be copied into the new variable on the assumption that the names are interchangeable. One setting was a segment count, while the replacement explicitly scales with the number of nodes. Preserving a numeral while changing its unit can produce a different repair plan.

The release also contains a documentation update for the Docker variable. There is a useful discrepancy in the tagged material. The general configuration page still prints 16 as the default, and the Docker variable table retains 200 beside the renamed variable. The implementation and packaged examples in the actual change establish the new value of 64. This is a case where reading the patch resolves an inconsistency in the accompanying documentation.

Segmentation and pacing control different work

The same configuration reference describes repairIntensity as a control over sleeping between segments. An intensity of one removes that sleep, while lower values reserve some of the elapsed time for waiting. Segment count determines the division of a repair. Intensity determines part of the pacing between those divisions.

Another setting, hangingRepairTimeoutMins, bounds how long Reaper waits for an individual repair. The documentation says that, on reaching the timeout, Reaper cancels the segment if possible and schedules it again within the same run. Increasing the number of segments aims to make those units less likely to reach the limit. It does not remove the timeout or turn a timed-out segment into a successful one.

Finer segmentation also means the service has more units to schedule and track. That is an immediate consequence of the new count. The generator and configuration descriptions support this operational tradeoff, without establishing a universal best count for every cluster.

I prefer a default explained in terms of a repair unit that can finish within its allotted time. Reaper 2.0.5 changes the default for newly registered runs and exposes the corresponding per-node setting in its container template. An explicitly configured older value remains a separate configuration choice, so understanding the effective setting requires looking at the supplied configuration as well as the release number.