An extract of this conversation should definitely be posted somewhere. Read a lot but never learnt all these bits...
On Fri, Aug 26, 2016 at 2:53 PM, Paulo Motta <pauloricard...@gmail.com> wrote: > > 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)? >>>>>> >>>>> >>>>> >>>> >>> >> >
