[
https://issues.apache.org/jira/browse/CASSANDRA-21552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18104413#comment-18104413
]
Stefan Miklosovic edited comment on CASSANDRA-21552 at 8/13/26 12:43 PM:
-------------------------------------------------------------------------
[~tommy_s] Okay I think this there an issue, actually. The only place where
{{force_repair}} is set to {{false}} is in {{updateFinishAutoRepairHistory}}
which is called via {{cleanupAndUpdateStats}}. {{RECORD_FINISH_REPAIR_HISTORY}}
is the only query which sets {{force_repair}} to {{false}}. Now, if we go to
forcefully repair and this fails then who is clearing that flag?
If anything in {{AutoRepair.repair}} fails between
{{updateStartAutoRepairHistory}} and {{cleanupAndUpdateStats}} then it will be
caught in that {{catch}} but {{force_repair}} is never set back to {{false}} as
it would be on the happy path. That means that {{isForceRepairSetForNode}} will
return {{true}} hence {{shouldSkipRepairDueToInterval}} will return false. In
other words it never comes to {{tooSoonToRunRepair}} if we do not change it
back to false on a failed repair so it will never be throttled as it was by
{{tooSoonToRunRepair}} previously.
was (Author: smiklosovic):
[~tommy_s] Okay I think this there an issue, actually. The only place where
{{force_repair}} is set to `false` is in `updateFinishAutoRepairHistory` which
is called via `cleanupAndUpdateStats`. RECORD_FINISH_REPAIR_HISTORY is the only
query which sets {{force_repair}} to {{false}}. Now, if we go to forcefully
repair and this fails then who is clearing that flag?
If anything in {{AutoRepair.repair}} fails between
`updateStartAutoRepairHistory` and `cleanupAndUpdateStats` then it will be
caught in that {{catch}} but {{force_repair}} is never set back to {{false}} as
it would be on the happy path. That means that {{isForceRepairSetForNode}} will
return {{true}} hence {{shouldSkipRepairDueToInterval}} will return false. In
other words it never comes to {{tooSoonToRunRepair}} if we do not change it
back to false on a failed repair so it will never be throttled as it was by
{{tooSoonToRunRepair}} previously.
> Force repair should ignore min_repair_interval
> ----------------------------------------------
>
> Key: CASSANDRA-21552
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21552
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Feature/Repair
> Reporter: Tommy Stendahl
> Assignee: Tommy Stendahl
> Priority: Normal
> Fix For: 5.0.x, 6.x, 7.x
>
> Attachments: ci_summary_driftx_CASSANDRA-21552-5.0_184.html,
> ci_summary_driftx_CASSANDRA-21552-6.0_113.html,
> ci_summary_driftx_CASSANDRA-21552-trunk_665.html,
> results_details_driftx_CASSANDRA-21552-5.0_184.tar.xz,
> results_details_driftx_CASSANDRA-21552-6.0_113.tar.xz,
> results_details_driftx_CASSANDRA-21552-trunk_665.tar.xz
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> If you set force repair for a node the repair is not triggered until
> min_repair_interval has expired, this could be several hours. This seams like
> a mistake, if you need to do a force repair you probably want it executed
> ASAP regardless of min_repair_interval.
> The problem is that in AutoRepair.java, tooSoonToRunRepair() is called before
> myTurnToRunRepair(). Since tooSoonToRunRepair() checks if min_repair_interval
> has elapsed and returns early if it hasn't, a node with force_repair set is
> still blocked from triggering immediate repair.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
