cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulo Motta <pauloricard...@gmail.com>
Subject Re: Upgrade cassandra 2.1.14 to 3.0.7
Date Mon, 19 Sep 2016 14:43:49 GMT
> If you do not feel ready for incremental repairs, just adding the '-full'
option to your 'nodetool repair' command should be enough to continue
repairing as you currently are once using 3.0.7.

This is not entirely true on 2.2+ after CASSANDRA-7586, since
anti-compaction is always executed after full repairs, so it will be more
expensive on 2.2+ than on 2.1. So after 2.2+ it's much cheaper to run
incremental repairs since repaired/unrepaired data is already being
seggregated anyway by anti-compaction after the first full repair.

Please note that this does not apply to subrange repair, which skips
anti-compaction entirely (CASSANDRA-10422), so it has the same cost as
previously.

2016-09-19 11:02 GMT-03:00 Alain RODRIGUEZ <arodrime@gmail.com>:

> Hi Jean,
>
> Our concern is the repair, in 3.0.7 repairs inc are by default. Then it
>> means that once we do the upgrade to 3.0.7 we must follow the migration
>> process of repairs inc for all our data in order to mark the sstables as
>> repaired ?
>
>
> If you do not feel ready for incremental repairs, just adding the '-full'
> option to your 'nodetool repair' command should be enough to continue
> repairing as you currently are once using 3.0.7. 'nodetool repair -inc'
> becomes the default 'nodetool repair' indeed, but you're not forced to use
> incremental repair because you will be using 3.0.7, that's why '-full'
> option was added. You did the hardest part in noticing this change and
> start wondering about it.
>
> C*heers,
> -----------------------
> Alain Rodriguez - @arodream - alain@thelastpickle.com
> France
>
> The Last Pickle - Apache Cassandra Consulting
> http://www.thelastpickle.com
>
> 2016-09-12 13:55 GMT+02:00 Paulo Motta <pauloricardomg@gmail.com>:
>
>> Migration procedure is no longer required for incremental repair as of
>> 2.1.4 since CASSANDRA-8004, which was the reason why the migration
>> procedure was required for LCS before. The migration procedure is only
>> useful now to skip validation on already repaired sstables in the first
>> incremental repair run by marking them as repaired before running the first
>> incremental repair, otherwise anti-compaction will mark them as repaired in
>> the first run since CASSANDRA-7586 on 2.2+.
>>
>> 2016-09-06 5:26 GMT-03:00 Jean Carlo <jean.jeancarl48@gmail.com>:
>>
>>> Hello guys
>>>
>>> We are planing to upgrade cassandra soon to the version 3.0.7 from
>>> 2.1.14. Our concern is the repair, in 3.0.7 repairs inc are by default.
>>> Then it means that once we do the upgrade to 3.0.7 we must follow the
>>> migration process of repairs inc for all our data in order to mark the
>>> sstables as repaired ? or we can just run directly the repair command
>>> without need to mark the sstables previously?
>>>
>>> My first test with ccm tells me that we don't need to mark the sstables
>>> because the repair in the 3.0.7 do it for you, but I want to ask if someone
>>> has done this migration and confirm my assumption
>>>
>>> Best regards.
>>>
>>> Jean Carlo
>>>
>>> "The best way to predict the future is to invent it" Alan Kay
>>>
>>
>>
>

Mime
View raw message