Thanks Alexander,
After roll restart the blocked repair job stopped and I was able to run
repair again.
Regards,
Robert
Robert Sicoie
On Wed, Sep 28, 2016 at 6:46 PM, Alexander Dejanovski <
a...@thelastpickle.com> wrote:
> Robert,
>
> You can restart them in any order, that doesn't make a
Robert,
You can restart them in any order, that doesn't make a difference afaik.
Cheers
Le mer. 28 sept. 2016 17:10, Robert Sicoie a
écrit :
> Thanks Alexander,
>
> Yes, with tpstats I can see the hanging active repair(s) (output
> attached). For one there are 31
Thanks Alexander,
Yes, with tpstats I can see the hanging active repair(s) (output attached).
For one there are 31 pending repair. On others there are less pending
repairs (min 12). Is there any recomandation for the restart order? The one
with more less pending repairs first, perhaps?
Thanks,
They will show up in nodetool compactionstats :
https://issues.apache.org/jira/browse/CASSANDRA-9098
Did you check nodetool tpstats to see if you didn't have any running repair
session ?
Just to make sure (and if you can actually do it), roll restart the cluster
and try again. Repair sessions can
Hi,
nodetool scrub won't help here, as what you're experiencing is most likely
that one SSTable is going through anticompaction, and then another node is
asking for a Merkle tree that involves it.
For understandable reasons, an SSTable cannot be anticompacted and
validation compacted at the same
Hi guys,
I have a cluster of 5 nodes, cassandra 3.0.5.
I was running nodetool repair last days, one node at a time, when I first
encountered this exception
*ERROR [ValidationExecutor:11] 2016-09-27 16:12:20,409
CassandraDaemon.java:195 - Exception in thread
Thread[ValidationExecutor:11,1,main]*