Just read the source and well… yup. I’m guessing now that the options are indeed only rolling repair on each node (with -pr stopping the duplicate work) or -st -9223372036854775808 -et 9223372036854775807 to actually cover all ranges. I didn’t walk through to test that, though.
Glad 3.0 is getting a little bit of love on improving repairs and communications / logging about them. -Jeff > On Apr 13, 2015, at 3:45 PM, Robert Coli <rc...@eventbrite.com> wrote: > > On Mon, Apr 13, 2015 at 3:33 PM, Jeff Ferland <j...@tubularlabs.com > <mailto:j...@tubularlabs.com>> wrote: > Nodetool repair -par: covers all nodes, computes merkle trees for each node > at the same time. Much higher IO load as every copy of a key range is scanned > at once. Can be totally OK with SSDs and throughput limits. Only need to run > the command one node. > > No? -par is just a performance (of repair) de-optimization, intended to > improve service time during repair. Doing -par without -pr on a single node > doesn't repair your entire cluster. > > Consider the following 7 node cluster, without vnodes : > > A B C D E F G > RF=3 > > You run a repair on node D, without -pr. > > D is repaired against B's tertiary replicas. > D is repaired against C's secondary replicas. > E is repaired against D's secondary replicas. > F is repaired against D's tertiary replicas. > Nodes A and G are completely unaffected and unrepaired, because D does not > share any ranges with them. > > repair with or without -par only covers all *replica* nodes. Even with > vnodes, you still have to run it on almost all nodes in most cases. Which is > why most users should save themselves the complexity and just do a rolling > -par -pr on all nodes, one by one. > > =Rob >
