Just one more thing. Make sure you run 'nodetool repair -full' instead
of just 'nodetool repair'. That's because the command's default was
changed in Cassandra 2.x. The default was full repair before that
change, but the new default now is incremental repair.
On 07/02/2024 10:28, Bowen Song via user wrote:
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
<https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/operations/opsRepairNodesMigration.html>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?
Thanks,
Kristijonas
On Sun, Feb 4, 2024 at 12:18 AM Alexander DEJANOVSKI
<adejanov...@gmail.com> 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
<sebast...@marsching.com> a écrit :
Hi,
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
night.
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 progress.
Best regards,
Sebastian
