В этом разделе описаны задачи периодического обслуживания Cassandra.
Антиэнтропийное обслуживание
Кольцевые узлы Apache Cassandra требуют периодического обслуживания для обеспечения согласованности на всех узлах. Чтобы выполнить это обслуживание, используйте следующую команду:
apigee-service apigee-cassandra apigee_repair -pr
Apigee рекомендует следующее при запуске этой команды:
- Запускайте на каждом узле Cassandra (во всех регионах или центрах обработки данных).
Запускайте по одному узлу за раз, чтобы обеспечить согласованность между всеми узлами в кольце. Одновременное выполнение ремонтных работ на нескольких узлах может ухудшить работоспособность Cassandra.
Чтобы проверить, успешно ли завершилось задание восстановления на узле, найдите в файле
system.log
узла запись с UUID последнего сеанса восстановления и фразой «сеанс завершен успешно». Вот пример записи журнала:INFO [AntiEntropySessions:1] 2015-03-01 10:02:56,245 RepairSession.java (line 282) [repair #2e7009b0-c03d-11e4-9012-99a64119c9d8] session completed successfully" Ref: https://support.datastax.com/hc/en-us/articles/204226329-How-to-check-if-a-scheduled-nodetool-repair-ran-successfully
- Запускать в периоды относительно низкой рабочей нагрузки (инструмент оказывает значительную нагрузку на систему).
- Запускайте не реже одного раза в семь дней, чтобы устранить проблемы, связанные с «забытыми удалениями» Кассандры.
- Запускайте на разных узлах в разные дни или запланируйте так, чтобы между запуском на каждом узле было несколько часов.
- Используйте опцию
-pr
(диапазон разделителей), чтобы указать только основной диапазон разделителей узла.
Если вы включили аутентификацию JMX для Cassandra , вы должны указать имя пользователя и пароль при вызове nodetool
. Например:
apigee-service apigee-cassandra apigee_repair -u username -pw password -pr
Вы также можете запустить следующую команду, чтобы проверить поддерживаемые параметры apigee_repair:
apigee-service apigee-cassandra apigee_repair -h
Примечание. apigee_repair
— это оболочка средства восстановления nodetool Cassandra, которая выполняет дополнительные проверки перед выполнением восстановления Cassandra.
Для получения дополнительной информации см. следующие ресурсы:
Ведение файла журнала
Журналы Cassandra хранятся в каталоге /opt/apigee/var/log/apigee-cassandra
на каждом узле. По умолчанию можно создать максимум 50 файлов журналов, каждый размером не более 20 МБ; по достижении этого предела старые журналы удаляются при создании новых журналов.
Если вы обнаружите, что файлы журналов Cassandra занимают слишком много места, вы можете изменить объем места, выделенного для файлов журналов, отредактировав настройки log4j.
- Отредактируйте
/opt/apigee/customer/application/cassandra.properties
, чтобы установить следующие свойства. Если этот файл не существует, создайте его:conf_logback_maxfilesize=20MB # max file size conf_logback_maxbackupindex=50 # max open files
- Перезапустите Cassandra, используя следующую команду:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
Обслуживание дискового пространства
Вам следует регулярно отслеживать использование дисков Cassandra, чтобы гарантировать, что не менее 50 процентов каждого диска свободны. Если загрузка диска превышает 50 процентов, мы рекомендуем вам добавить больше дискового пространства, чтобы уменьшить процент использования.
Cassandra автоматически выполняет следующие операции, чтобы уменьшить использование собственного диска:
- Удаление токена аутентификации по истечении срока действия токена. Однако в зависимости от вашей конфигурации для освобождения дискового пространства, которое использовали токены, может потребоваться несколько недель. Если автоматического удаления недостаточно для сохранения достаточного места на диске, обратитесь в службу поддержки, чтобы узнать об удалении токенов вручную для восстановления места.
Примечание по сжатию данных: начиная с Edge для частного облака 4.51.00, новые установки Apigee Cassandra будут создавать пространства ключей со стратегией выравниваемого уплотнения .
При установке более старых версий Edge for Private Cloud, обновленных до Private Cloud 4.51.00, будет по-прежнему сохраняться предыдущая стратегия сжатия. Если существующей стратегией сжатия является SizeTieredCompactionStrategy, мы рекомендуем перейти на LeveledCompactionStrategy, которая обеспечивает лучшее использование диска.
Примечание. Когда Cassandra выполняет сжатие данных, это может потребовать значительного количества циклов ЦП и памяти. Но использование ресурсов должно вернуться в норму после завершения уплотнения. Вы можете запустить команду 'Nodetool compactionstats'
на каждом узле, чтобы проверить, выполняется ли сжатие. Вывод compactionstats
информирует вас о наличии ожидающих выполнения уплотнений и примерном времени их завершения.