> I must admit that I fail to understand currently how running repair with -pr could leave unrepaired data though, even when ran on all nodes in all DCs, and how that could be specific to incremental repair (and would appreciate if someone shared the explanation).
Anti-compaction, which marks tables as repaired, is disabled for partial range repairs (which includes partitioner-range repair) to avoid the extra I/O cost of needing to run anti-compaction multiple times in a node to repair it completely. For example, there is an optimization which skips anti-compaction for sstables fully contained in the repaired range (only the repairedAt field is mutated), which is leveraged by full range repair, which would not work in many cases for partial range repairs, yielding higher I/O. 2016-08-26 10:17 GMT-03:00 Stefano Ortolani <ostef...@gmail.com>: > I see. Didn't think about it that way. Thanks for clarifying! > > > On Fri, Aug 26, 2016 at 2:14 PM, Paulo Motta <pauloricard...@gmail.com> > wrote: > >> > What is the underlying reason? >> >> Basically to minimize the amount of anti-compaction needed, since with >> RF=3 you'd need to perform anti-compaction 3 times in a particular node to >> get it fully repaired, while without it you can just repair the full node's >> range in one run. Assuming you run repair frequent enough this will not be >> a big deal, since you will skip already repaired data in the next round so >> you will not have the problem of re-doing work as in non-inc non-pr repair. >> >> 2016-08-26 7:57 GMT-03:00 Stefano Ortolani <ostef...@gmail.com>: >> >>> Hi Paulo, could you elaborate on 2? >>> I didn't know incremental repairs were not compatible with -pr >>> What is the underlying reason? >>> >>> Regards, >>> Stefano >>> >>> >>> On Fri, Aug 26, 2016 at 1:25 AM, Paulo Motta <pauloricard...@gmail.com> >>> wrote: >>> >>>> 1. Migration procedure is no longer necessary after CASSANDRA-8004, and >>>> since you never ran repair before this would not make any difference >>>> anyway, so just run repair and by default (CASSANDRA-7250) this will >>>> already be incremental. >>>> 2. Incremental repair is not supported with -pr, -local or -st/-et >>>> options, so you should run incremental repair in all nodes in all DCs >>>> sequentially (you should be aware that this will probably generate inter-DC >>>> traffic), no need to disable autocompaction or stopping nodes. >>>> >>>> 2016-08-25 18:27 GMT-03:00 Aleksandr Ivanov <ale...@gmail.com>: >>>> >>>>> I’m new in Cassandra and trying to figure out how to _start_ using >>>>> incremental repairs. I have seen article about “Migrating to incremental >>>>> repairs” but since I didn’t use repairs before at all and I use Cassandra >>>>> version v3.0.8, then maybe not all steps are needed which are mentioned in >>>>> Datastax article. >>>>> Should I start with full repair or I can start with executing >>>>> “nodetool repair -pr my_keyspace” on all nodes without autocompaction >>>>> disabling and node stopping? >>>>> >>>>> I have 6 datacenters with 6 nodes in each DC. Is it enough to run >>>>> “nodetool repair -pr my_keyspace” in one DC only or it should be >>>>> executed >>>>> on all nodes in _all_ DCs? >>>>> >>>>> I have tried to perform “nodetool repair -pr my_keyspace” on all >>>>> nodes in all datacenters sequentially but I still can see non repaired >>>>> SSTables for my_keyspace (Repaired at: 0). Is it expected behavior if >>>>> during repair data in my_keyspace wasn’t modified (no writes, no reads)? >>>>> >>>> >>>> >>> >> >
