cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reynald Bourtembourg <reynald.bourtembo...@esrf.fr>
Subject Migrating to incremental repairs
Date Wed, 18 Nov 2015 15:45:49 GMT
Hi,

We currently have a 3 nodes Cassandra cluster with RF = 3.
We are using Cassandra 2.1.7.

We would like to start using incremental repairs.
We have some tables using LCS compaction strategy and some others using 
STCS.

Here is the procedure written in the documentation:

To migrate to incremental repair, one node at a time:

 1. Disable compaction on the node using nodetool disableautocompaction.
 2. Run the default full, sequential repair.
 3. Stop the node.
 4. Use the tool sstablerepairedset to mark all the SSTables that were
    created before you disabled compaction.
 5. Restart cassandra


In our case, a full sequential repair takes about 5 days.
If I follow the procedure described above and if my understanding is 
correct, it's gonna take at least 15 days (3 repairs of 5 days) before 
to be able to use the incremental repairs, right(?), since we need to do 
it one node at a time (one full sequential repair per node?).

If my understanding is correct, what is the rationale behind the fact 
that we need to run a full sequential repair once for each node?
I understood a full sequential repair would repair all the sstables on 
all the nodes. So doing it only once should be enough, right?

Is it possible to do the following instead of what is written in the 
documentation?:
  - disableautocompaction on all nodes at the same time
  - run the full sequential repair
  - For each node:
         - stop one node
         - Use the tool sstablerepairedset to mark all the SSTables that 
were created before you disabled compaction.
         - Restart Cassandra
Without having to run the full sequential repair 3 times?

The documentation states that if we don't execute this migration 
procedure, the first time we will run incremental repair, Cassandra will 
perform size-tiering on all SSTables because the repair/unrepaired 
status is unknown and this operation can take a long time.
Do you think this operation could take more than 15 days in our case?

I understood that we only need to use sstablerepairedset on the SSTables 
related to the tables using LCS compaction strategy and which were 
created before the auto compaction was disabled.
Is my understanding correct?

The documentation is not very explicit but I suppose the following sentence:
"4. Use the tool sstablerepairedset to mark all the SSTables that were 
created before you disabled compaction."
means we need to invoke "sstablerepairedset --is-repaired -f 
list_of_sstable_names.txt" on the LCS SSTables that were created before 
the compaction was disabled.

Is this correct?

Do we need to enableautocompaction again after the Cassandra restart or 
is it done automatically?

Would you recommend us to upgrade our Cassandra version before starting 
the incremental repair migration?

Thank you for your help and sorry for the long e-mail.

Reynald






Mime
View raw message