You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Marcus Eriksson (JIRA)" <ji...@apache.org> on 2017/08/17 15:34:00 UTC
[jira] [Commented] (CASSANDRA-13758) Incremental repair sessions
shouldn't be deleted if they still have sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-13758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16130687#comment-16130687 ]
Marcus Eriksson commented on CASSANDRA-13758:
---------------------------------------------
+1 - but it might make sense to log something if a session is kept because it contains data? Feel free to add that on commit if you agree
> Incremental repair sessions shouldn't be deleted if they still have sstables
> ----------------------------------------------------------------------------
>
> Key: CASSANDRA-13758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13758
> Project: Cassandra
> Issue Type: Bug
> Reporter: Blake Eggleston
> Assignee: Blake Eggleston
> Labels: incremental_repair
> Fix For: 4.0
>
>
> The incremental session cleanup doesn't verify that there are no remaining sstables marked as part of the repair before deleting it. Deleting a successful repair session which still has outstanding sstables will cause those sstables to be demoted to unrepaired, creating an inconsistency.
> This typically wouldn't be an issue, since we'd expect the sstables to long since have been promoted / demoted. However, I've seen a few ref leak issues which can cause sstables to get stuck. Those have been fixed, but we should still protect against that edge case to prevent inconsistencies caused by future (or currently unknown) bugs.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org