Re: Repairing without -pr shows unexpected out-of-sync ranges

> 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

Re: Repairing without -pr shows unexpected out-of-sync ranges

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,

Re: Repairing without -pr shows unexpected out-of-sync ranges

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

Re: Repairing without -pr shows unexpected out-of-sync ranges

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

Repairing without -pr shows unexpected out-of-sync ranges

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