Not disabling auto-compaction may result in repaired SSTables getting compacted together with unrepaired SSTables before the repair state is set on them, which leads to mismatch in the repaired data between nodes, and potentially very expensive over-streaming in a future full repair. You should follow the documented and tested steps and not improvise or getting creative if you value your data and time.

On 06/02/2024 23:55, Kristijonas Zalys wrote:

Hi folks,

Thank you all for your insight, this has been very helpful.

I was going through the migration process here <>and I’m not entirely sure why disabling autocompaction on the node is required? Could anyone clarify what would be the side effects of not disabling autocompaction and starting with step 2 of the migration?



On Sun, Feb 4, 2024 at 12:18 AM Alexander DEJANOVSKI <> wrote:

    Hi Sebastian,

    That's a feature we need to implement in Reaper. I think
    disallowing the start of the new incremental repair would be
    easier to manage than pausing the full repair that's already
    running. It's also what I think I'd expect as a user.

    I'll create an issue to track this.

    Le sam. 3 févr. 2024, 16:19, Sebastian Marsching
    <> a écrit :


        2. use an orchestration tool, such as Cassandra Reaper, to
        take care of that for you. You will still need monitor and
        alert to ensure the repairs are run successfully, but fixing
        a stuck or failed repair is not very time sensitive, you can
        usually leave it till Monday morning if it happens at Friday

        Does anyone know how such a schedule can be created in
        Cassandra Reaper?

        I recently learned the hard way that running both a full and
        an incremental repair for the same keyspace and table in
        parallel is not a good idea (it caused a very unpleasant
        overload situation on one of our clusters).

        At the moment, we have one schedule for the full repairs
        (every 90 days) and another schedule for the incremental
        repairs (daily). But as full repairs take much longer than a
        day (about a week, in our case), the two schedules collide.
        So, Cassandra Reaper starts an incremental repair while the
        full repair is still in process.

        Does anyone know how to avoid this? Optimally, the full repair
        would be paused (no new segments started) for the duration of
        the incremental repair. The second best option would be
        inhibiting the incremental repair while a full repair is in

        Best regards,

Reply via email to