> is (2) a direct consequence of a repair on the full token range (and thus
anti-compaction ran only on a subset of the RF nodes)?
Not necessarily, because even with -pr enabled the nodes will be
responsible for different ranges, so they will flush and compact at
different instants. The effect of
I was wondering: is (2) a direct consequence of a repair on the full
token range (and thus anti-compaction ran only on a subset of the RF
nodes)?. If I understand correctly, a repair with -pr should fix this,
at the cost of all nodes performing the anticompaction phase?
Cheers,
Stefano
On Tue, Se
Didn't know about (2), and I actually have a time drift between the nodes.
Thanks a lot Paulo!
Regards,
Stefano
On Thu, Sep 22, 2016 at 6:36 PM, Paulo Motta
wrote:
> There are a couple of things that could be happening here:
> - There will be time differences between when nodes participating re
There are a couple of things that could be happening here:
- There will be time differences between when nodes participating repair
flush, so in write-heavy tables there will always be minor differences
during validation, and those could be accentuated by low resolution merkle
trees, which will aff
Hi,
I am seeing something weird while running repairs.
I am testing 3.0.9 so I am running the repairs manually, node after node,
on a cluster with RF=3. I am using a standard repair command (incremental,
parallel, full range), and I just noticed that the third node detected some
ranges out of sync
