cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Knighton (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11696) Incremental repairs can mark too many ranges as repaired
Date Thu, 23 Jun 2016 07:50:17 GMT


Joel Knighton commented on CASSANDRA-11696:


All your testall/dtest runs looked clean with the exception of dtests on trunk. Trunk had
some known flaky failures and failures on four tests that were not tagged as flaky. Some of
these have failed on trunk recently - the failures looked like [CASSANDRA-12072] and all seemed
related to timeouts on driver connections/cluster setup, so I'm not too concerned. They all
passed locally. I triggered one more trunk dtest run - this time, two different tests failed
in comparable ways, so I'm pretty sure it is part of some larger environmental problem. Again,
the untagged failing tests passed locally. I'm comfortable with these test results.

> Incremental repairs can mark too many ranges as repaired
> --------------------------------------------------------
>                 Key: CASSANDRA-11696
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Joel Knighton
>            Assignee: Marcus Eriksson
>            Priority: Critical
>             Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
> Incremental repairs are tracked using a parent session - a subordinate repair session
is created for each range in the repair. When a node participating in the repair receives
a validation request, it will reference the sstables in the parent repair session. When all
subordinate sessions conclude, each node anticompacts SSTables based on the parent repair
session for the whole range of the repair, but these referenced SSTables may have only been
present for the validation of some subset of the ranges because the SSTables were created
concurrent with the parent repair session.

This message was sent by Atlassian JIRA

View raw message