[jira] [Commented] (CASSANDRA-14939) fix some operational holes in incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-14939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171836#comment-17171836 ] Blake Eggleston commented on CASSANDRA-14939: - [~marcuse] rebased on current trunk and addressed all review comments > fix some operational holes in incremental repair > > > Key: CASSANDRA-14939 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14939 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0 > > > Incremental repair has a few operational rough spots that make it more > difficult to fully automate and operate at scale than it should be. > * Visibility into whether pending repair data exists for a given token range. > * Ability to force promotion/demotion of data for completed sessions instead > of waiting for compaction. > * Get the most recent repairedAt timestamp for a given token range. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14939) fix some operational holes in incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-14939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17105790#comment-17105790 ] Jordan West commented on CASSANDRA-14939: - [~kohlisankalp] I don't personally have enough background to comment on this ticket. With fresh eyes I saw it as a potential candidate for a follow up release since it hasn't been worked on for over one year and looks to be a set of improvements on an existing feature. I defer to those involved with the ticket and/or the community if its better to start a conversation on the mailing list. > fix some operational holes in incremental repair > > > Key: CASSANDRA-14939 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14939 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0 > > > Incremental repair has a few operational rough spots that make it more > difficult to fully automate and operate at scale than it should be. > * Visibility into whether pending repair data exists for a given token range. > * Ability to force promotion/demotion of data for completed sessions instead > of waiting for compaction. > * Get the most recent repairedAt timestamp for a given token range. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14939) fix some operational holes in incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-14939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17105760#comment-17105760 ] Sankalp Kohli commented on CASSANDRA-14939: --- I think we should do this as part of 4.0-beta as it is important to users who will use IR in 4.0. IR has major changes in 4.0 and we hope lot more users will use this in 4.0!! cc [~jwest] > fix some operational holes in incremental repair > > > Key: CASSANDRA-14939 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14939 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0 > > > Incremental repair has a few operational rough spots that make it more > difficult to fully automate and operate at scale than it should be. > * Visibility into whether pending repair data exists for a given token range. > * Ability to force promotion/demotion of data for completed sessions instead > of waiting for compaction. > * Get the most recent repairedAt timestamp for a given token range. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14939) fix some operational holes in incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-14939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17034275#comment-17034275 ] Stefan Miklosovic commented on CASSANDRA-14939: --- Is there any chance this will appear in upcomming 4.x release? Is anybody working on this atm? > fix some operational holes in incremental repair > > > Key: CASSANDRA-14939 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14939 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0 > > > Incremental repair has a few operational rough spots that make it more > difficult to fully automate and operate at scale than it should be. > * Visibility into whether pending repair data exists for a given token range. > * Ability to force promotion/demotion of data for completed sessions instead > of waiting for compaction. > * Get the most recent repairedAt timestamp for a given token range. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14939) fix some operational holes in incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-14939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16774116#comment-16774116
]
Marcus Eriksson commented on CASSANDRA-14939:
-
in general, this looks very nice and will be a huge help
General stuff
* We keep the LocalSessions around for 1 day in system.repairs - I guess it is
possible to give incomplete information for summarizeRepaired after bounce for
example? (I have no real solution other than keeping them around for a longer
time)
ColumnFamilyStore;
* test(s) for getPendingRepairStats
* in getPendingRepairStats there is a potential NPE - the pending repair
status can be removed between the isPendingRepair check and getting the
pendingRepair UUID from the sstable
* when we use {{runWithCompactionsDisabled}} we could potentially pass in the
ranges we need to cancel compactions for (totally ok leaving this for a future
ticket though)
* potential NPE - {{sst.isPendingRepair}} call first, then
{{sst.getPendingRepair}} in the {{runWithCompactionsDisabled}} call
CompactionStrategyManager;
* in {{releaseRepairedData}} - we should probably make sure all the callables
are cancelled if we catch that exception there, otherwise we might keep the
sstables marked as compacting forever
PendingRepairManager;
* I think strategies can be removed even though we have the read lock -
{{Set sstables = get(sessionID).getSSTables();}} could NPE in
that case
Range;
* new {{Range.intersects(..)}} method should probably have a test
* same with new {{subtract}} method - both get tested indirectly, but might be
good with a few direct ones
LocalSessions;
* in {{getPendingStats}} sessionIDs set is not used
* in {{getPendingStats}} when checking {{if (!Iterables.any(ranges, r ->
r.intersects(session.ranges)))}} session could be null - there is a null check
right below which we could move up.
RepairedState;
* This class could use a more comments
PendingStat;
* In {{addSSTable}}, instead of checking
{{Preconditions.checkArgument(sessionID != null);}} we should probably just
skip the sstable as it means it has been moved out of pending
PendingStats;
* seems to be a mismatch in the columns in {{to/fromComposite}}
SchemaArgsParser;
* Untested
I changed {{RepairAdmin}} nodetool command to use subcommands to reduce some of
the manual parameter verification;
[https://github.com/krummas/cassandra/commits/blake/14939-trunk-nodetool]
> fix some operational holes in incremental repair
>
>
> Key: CASSANDRA-14939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14939
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Major
> Fix For: 4.0
>
>
> Incremental repair has a few operational rough spots that make it more
> difficult to fully automate and operate at scale than it should be.
> * Visibility into whether pending repair data exists for a given token range.
> * Ability to force promotion/demotion of data for completed sessions instead
> of waiting for compaction.
> * Get the most recent repairedAt timestamp for a given token range.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14939) fix some operational holes in incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-14939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757075#comment-16757075
]
Stefan Podkowinski commented on CASSANDRA-14939:
Can you please also add {{parentRepairSession}} to
[this|https://github.com/apache/cassandra/blob/a05785d82c621c9cd04d8a064c38fd2012ef981c/src/java/org/apache/cassandra/repair/RepairSession.java#L268]
log statement, so we can get a link between parent and child sessionIds in the
log files?
> fix some operational holes in incremental repair
>
>
> Key: CASSANDRA-14939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14939
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Major
> Fix For: 4.0
>
>
> Incremental repair has a few operational rough spots that make it more
> difficult to fully automate and operate at scale than it should be.
> * Visibility into whether pending repair data exists for a given token range.
> * Ability to force promotion/demotion of data for completed sessions instead
> of waiting for compaction.
> * Get the most recent repairedAt timestamp for a given token range.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14939) fix some operational holes in incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-14939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724481#comment-16724481 ] Blake Eggleston commented on CASSANDRA-14939: - /cc [~mbyrd], [~spo...@gmail.com] > fix some operational holes in incremental repair > > > Key: CASSANDRA-14939 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14939 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Major > > Incremental repair has a few operational rough spots that make it more > difficult to fully automate and operate at scale than it should be. > * Visibility into whether pending repair data exists for a given token range. > * Ability to force promotion/demotion of data for completed sessions instead > of waiting for compaction. > * Get the most recent repairedAt timestamp for a given token range. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
