Сжатие Кассандры против ремонта против очистки

cleanup - это уплотнение, которое просто удаляет вещи за пределами диапазона (ов) токенов узлов. У repair есть «уплотнение проверки» для построения дерева Меркла для сравнения с другими узлами, поэтому часть nodetool repair будет иметь уплотнение.

Может ли задача восстановления выполняться во время выполнения задачи уплотнения или очищаться во время выполнения задачи уплотнения?

Существует общий пул уплотнений для обычных уплотнений, ремонта, очистки, очистки и т. Д. Это параметр concurrent_compactors в cassandra.yaml, который по умолчанию представляет собой комбинацию количества ядер и каталогов данных: https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L572

Очистка - это операция, которую нужно выполнять еженедельно в качестве ремонта?

нет, только после того, как действительно изменится топология.

Почему операцию восстановления нужно выполнять вручную, а это не в поведении Cassandra по умолчанию?

Его руководство, потому что его требования могут сильно отличаться от ваших данных и gc_grace требований. https://issues.apache.org/jira/browse/CASSANDRA-10070 переносит его внутрь Кассандры, хотя в будущем это будет автоматически.

Каковы основные правила технического обслуживания кластера?

Я бы сказал (мнение):

• Regular backups (depending on requirements, and acceptable data loss this can be anything from weekly/daily to constantly with incremental).
  • This is just as much for "internal" mistakes ("Opps i deleted a customer") as outages. Even with strong multi-dc replication you want some minimum backups.
• Убедитесь, что восстановление завершено для всех таблиц, которые были удалены хотя бы один раз в течение времени gc_grace этих таблиц.
• Хранилище показателей и журналов очень важно, если вы хотите иметь возможность отлаживать проблемы.