В моей таблице включена стратегия сжатия временного окна (TWCS), по какой-то причине у меня много SStables только с надгробиями.
Когда я выполняю ручное уплотнение одной стойки, она не удаляется. Если я запустил reapir, он объединит все sstables в один, что нарушит TWCS.
Согласно документации по команде nodetool scrub:
Scrub автоматически отбрасывает поврежденные данные и удаляет все захороненные строки, которые превысили период gc_grace таблицы.
Присоединится ли это ко всем конюшням?
Краткий ответ: скраб не присоединяется к стойле.
Длинный ответ: продолжайте читать.
Я проверил код в Cassandra 3.11.2, но код похож на 3.0 и 2.2.
Стойки очищаются параллельно, используя нити уплотнения, каждая резьба очищает одну стойку.
Как вы можете видеть в ColumnFamilyStore.java команда scrub запускается с использованием CompactionManager потоков.
Интересная функция для проверки: parallelAllSSTableOperation. Все живые sstables (за исключением тех, которые отмечены как подозрительные - например, из-за некоторых исключений во время уплотнения), принадлежащие таблице, помечаются как уплотняющие, все уплотнения, выполняемые в этой таблице, выполняется пауза для https, и операция hrefrer выполняется для https: a //github.com/apache/cassandra/blob/1d506f9d09c880ff2b2693e3e27fa58c02ecf398/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L313 "rel =" nofollow> в каждом soreferrer, параллельном, nofollow .
В случае скраба операция следующая: scrubOne, который вызывает Scrubber.scrub (). Это устаревший sstable и создает новый sstable, который содержит живые строки.
В конце parallelAllSSTableOperation список sstables, помеченных как сжатые, должен быть пустым, и операция будет успешной. Соединение стабильных элементов не производится.
Итак, вы можете видеть, что инструмент очистки является агрессивным: он заменяет старые sstables, отбрасывая надгробные камни и сохраняя активные строки в новых sstables.
Надеюсь, это поможет и я ничего не пропустил :).
