Задачи по обслуживанию Apache Cassandra

В этом разделе описываются задачи периодического обслуживания Cassandra.

Обслуживание антиэнтропии

Узлы кольца Apache Cassandra требуют периодического обслуживания для обеспечения согласованности между всеми узлами. Для этого используйте следующую команду:

apigee-service apigee-cassandra apigee_repair -pr

При выполнении этой команды Apigee рекомендует следующее:

  • Выполните на каждом узле Cassandra (во всех регионах или центрах обработки данных).

  • Запускайте по одному узлу за раз, чтобы обеспечить согласованность между всеми узлами в кольце. Одновременное выполнение заданий по восстановлению на нескольких узлах может нарушить работу Cassandra.

    Чтобы проверить, успешно ли завершено восстановление узла, найдите в файле system.log узла запись с UUID последнего сеанса восстановления и фразой "session completed successfully" (сеанс успешно завершен). Пример записи в журнале:

    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
  • Запускайте инструмент в периоды относительно низкой рабочей нагрузки, поскольку он значительно нагружает систему.
  • Запускайте по крайней мере каждые семь дней, чтобы устранить проблемы, связанные с "забытыми удалениями" Cassandra.
  • Запускайте его на разных узлах в разные дни или запланируйте его так, чтобы между запусками на каждом узле проходило несколько часов.
  • Используйте параметр -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 repair в Cassandra, которая выполняет дополнительные проверки перед восстановлением Cassandra.

Дополнительную информацию см. в указанных ниже ресурсах.

Обслуживание файлов журналов

Журналы Cassandra хранятся в каталоге /opt/apigee/var/log/apigee-cassandra на каждом узле. По умолчанию можно создать не более 50 файлов журнала, каждый из которых может иметь размер не более 20 МБ. По достижении этого лимита старые журналы удаляются при создании новых.

Если вы обнаружите, что файлы журнала Cassandra занимают слишком много места, вы можете изменить объем пространства, выделенного для файлов журнала, отредактировав настройки log4j.

  1. Измените /opt/apigee/customer/application/cassandra.properties, чтобы задать следующие свойства: Если такого файла нет, создайте его: 
    conf_logback_maxfilesize=20MB
# max file size
conf_logback_maxbackupindex=50 # max open files
  2. Перезапустите Cassandra с помощью следующей команды: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart

Обслуживание места на диске

Регулярно проверяйте использование диска Cassandra, чтобы убедиться, что на каждом диске свободно не менее 50 % места. Если этот показатель превышает 50 %, рекомендуем добавить место на диске.

Cassandra автоматически выполняет следующие операции, чтобы уменьшить использование диска:

  • Удаление токенов аутентификации по истечении срока их действия. Однако, в зависимости от конфигурации, на освобождение места на диске, которое занимали токены, может уйти пара недель. Если автоматического удаления недостаточно для поддержания достаточного объема свободного места на диске, обратитесь в службу поддержки, чтобы узнать, как удалить токены вручную.

  • Примечание о сжатии данных. Начиная с версии Edge для Private Cloud 4.51.00, новые установки Apigee Cassandra будут создавать пространства ключей с стратегией выровненного сжатия.

    В установленных ранее версиях Edge for Private Cloud, которые были обновлены до Private Cloud 4.51.00, будет по-прежнему использоваться прежняя стратегия сжатия. Если используется стратегия SizeTieredCompactionStrategy, рекомендуем перейти на LeveledCompactionStrategy, которая обеспечивает более эффективное использование диска.

Примечание. Сжатие данных в Cassandra может занимать значительное количество циклов ЦП и памяти. но после завершения сжатия использование ресурсов должно вернуться к норме. Чтобы проверить, выполняется ли сжатие, можно запустить команду 'Nodetool compactionstats' на каждом узле. Выходные данные compactionstats сообщают, есть ли ожидающие выполнения сжатия и расчетное время их завершения.