Hi Marcus,
thanks for that quick reply. I did also look at:
http://www.datastax.com/documentation/cassandra/2.1/cassandra/operations/ops_repair_nodes_c.html
which describes the same process, it's 2.1.x, so I see that 2.1.2+ is
not covered there. I did upgrade my testcluster to 2.1.2 and with your
hint I take a look at sstablemetadata from a non "migrated" node and
there are indeed "Repaired at" entries on some sstables already. So if I
got this right, in 2.1.2+ there is nothing to do to switch to
incremental repairs (apart from running the repairs themself).
But one thing I see during testing is that there are many sstables, with
small size:
- in total there are 5521 sstables on one node
- 115 sstables are bigger than 1MB
- 4949 sstables are smaller than 10kB
I don't know where they came from - I found one piece of information
where this happend when cassandra was low on heap which happend to me
while running tests (the suggested solution is to trigger compaction via
JMX).
Question for me: I did disable autocompaction on some nodes of our test
cluster as the blog and docs said. Should/can I reenable autocompaction
again with incremental repairs?
Cheers,
Roland
