cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulo Motta <pauloricard...@gmail.com>
Subject Re: How to start using incremental repairs?
Date Mon, 12 Sep 2016 11:56:15 GMT
> Can you clarify me please if what you said here applies for the version
2.1.14.

yes

2016-09-06 5:50 GMT-03:00 Jean Carlo <jean.jeancarl48@gmail.com>:

> Hi Paulo
>
> Can you clarify me please if what you said here
>
> 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.
>
> applies for the version 2.1.14. I ask because I see that the jira
> CASSANDRA-8004 is resolved for the version 2.1.2 and we are considering to
> migrate to repairs inc before go to the version 3.0.x
>
> Thhx :)
>
>
> Saludos
>
> Jean Carlo
>
> "The best way to predict the future is to invent it" Alan Kay
>
> On Fri, Aug 26, 2016 at 9:04 PM, Stefano Ortolani <ostefano@gmail.com>
> wrote:
>
>> 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 <pauloricardomg@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 <ostefano@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 <pauloricardomg@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 <ostefano@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 <
>>>>>> pauloricardomg@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 <alekiv@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)?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message