Очистка пространства в почти полном узле Cassandra

Команды, которые вы представили в своем вопросе, делают несколько неверных предположений. Во-первых, «ремонт» не должен и не будет экономить место. Все, что делает ремонт, — это находит несоответствия между разными репликами и исправляет их. Он либо ничего не сделает (если нет несоответствий), либо добавит данные, а не удалит данные. Во-вторых, «очистка» — это то, что вам нужно сделать после добавления новых узлов в кластер — после того, как каждый узел отправил часть своих данных на новый узел, «очистка» удаляет данные со старых узлов. Но очистка не актуальна, если не добавлен узел.

Возможно, вам нужна команда «compact». Это может сэкономить место, но только если вы знаете, что у вас было много перезаписей (перезаписи существующих строк), удалений или истечения срока действия данных (TTL). Какую стратегию уплотнения вы используете? Если это стандартная стратегия многоуровневого сжатия (STCS), вы можете начать крупное уплотнение (nodetool compact), но должны знать о большом риске:

Основное сжатие объединяет все данные в один sstable (формат файла Cassandra на диске), удаляя удаленные, просроченные или перезаписанные данные. Однако во время этого процесса сжатия у вас есть и входные, и выходные файлы, и в худшем случае это может удвоить использование вашего диска и может привести к сбою, если диск заполнен более чем на 50%. Вот почему во многих практических руководствах Cassandra рекомендуется никогда не заполнять более 50% диска. Но это только худший случай. Вы можете обойтись меньшим количеством свободного места, если знаете, что выходной файл будет намного меньше входного (поскольку большая часть данных была удалена). Возможно, более полезно, если у вас много отдельных таблиц (семейство столбцов), вы можете сжимать каждую отдельно (как вы предложили, от меньшего к большему), и максимальный объем дискового пространства, необходимый временно во время сжатия, может быть намного меньше 50% диска.