Hi
>you should reach an end as the scrub is applied to a list of sstables
>calculated scrub start (I believe).What I observed is that in data folder
>almost no original SSTables remained, but scrub still ran. So I suspect
>processing each new appearing table.
On Monday, October 29, 2018 8:34 PM, Alain RODRIGUEZ
wrote:
Hello,
should autocompaction be disabled before running scrub?
I would say the other way around, to be sure to leave some room to regular
compactions, you could try to run scrub with the following option
`nodetool scrub -j 1` (-j / --jobs allow controlling the number of compactor
threads to use). Depending on the rhythm you want to give to compaction
operations, you can tune this number and the ‘concurrent_compactor' option.
It seems that scrub processes each new created table and never ends.
Depending on the command that was run, if nothing was specified, nodetool scrub
might be running on the whole node (or keyspace?), which can be a lot, so when
an SSTable finishes, another might well start, for quite a while. But you
should reach an end as the scrub is applied to a list of sstables calculated
scrub start (I believe).
Here is what I can share from my understanding. If you believe there might be
an issue with your version of Cassandra or want to make sure that 'nodetool
scrub' behaves as described, reading the code and/or observing writ time of the
files that are getting compacted (SCRUB) is a way to go.
C*heers,---Alain Rodriguez - alain@thelastpickle.comFrance
/ Spain
The Last Pickle - Apache Cassandra Consultinghttp://www.thelastpickle.com
Le lun. 29 oct. 2018 à 16:18, Vlad a écrit :
Hi,
should autocompaction be disabled before running scrub?It seems that scrub
processes each new created table and never ends.
Thanks.
