You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Jean Carlo <je...@gmail.com> on 2016/09/06 08:26:54 UTC
Upgrade cassandra 2.1.14 to 3.0.7
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
Re: Upgrade cassandra 2.1.14 to 3.0.7
Posted by Paulo Motta <pa...@gmail.com>.
> 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 <ar...@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 <pa...@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 <je...@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
>>>
>>
>>
>
Re: Upgrade cassandra 2.1.14 to 3.0.7
Posted by Alain RODRIGUEZ <ar...@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 <pa...@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 <je...@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
>>
>
>
Re: Upgrade cassandra 2.1.14 to 3.0.7
Posted by Paulo Motta <pa...@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 <je...@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
>