7.5.4 Техобслуживание очереди сообщений

В случае озможны два варианта восстановления работоспособности кластера RabbitMQ:

  • c сохранением данных (пользователи, виртуальные хосты, политики, очереди приложений);
  • без сохранения данных (вся информация в очереди сообщений принудительно удаляется).

Первый вариант применим, если кластер не стартует или в его работе наблюдаются большие задержки, вызванные эффектом split-brain (при активации политик HA). В этом случае потребуется выполнить меры по восстановлению очереди сообщений, предприняв следующие действия:

  1. Выбрать узел с последней релевантной информацией (тот, который не перезагружался и не давал сбой).
  2. Исключить из кластера другие узлы.

На исключаемых из кластера узлах выполните (последовательно) команды:

rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl start_app

Если узлы не выходят из кластера (команды не исполняются, зависания), то необходимо принять к ним жёсткие меры, со стороны нормально функционирующего узла (например – node1). Выполните команды:

rabbitmqctl forget_cluster_node <node2> rabbitmqctl forget_cluster_node <node3>

В результате:

  • если команды выполняются успешно, то в кластере останется только нода node1;
  • если команды не выполнятся, то появляются ошибки и необходимо выполнить ряд следующих действий:
    • остановить на нерабочих узлах кластера сервисы RabbitMQ: systemctl stop rabbitmq-server;
    • запустить (на нерабочих узлах) сервис вручную – как приложение: rabbitmq-server -detached;
    • выполнить команды: rabbitmqctl stop_app; rabbitmqctl reset.
  1. После выполненного сброса завести выведенные узлы (node2 и node3) обратно в кластер RabbitMQ.

Выполните на каждом узле следующие команды присоединения к кластеру и запуска:

rabbitmqctl join_cluster rabbit@node1 rabbitmqctl start_app
  1. Проверьте состояние кластера: rabbitmqctl cluster_status.
В случае активной политики HA (ha-mode: all, ha-sync-mode: automatic) потребуется дождаться синхронизации данных (на других узлах).

7.5.4.1 Экспорт определения

Для экспорта определений с помощью rabbitmqctl используйте команду:

rabbitmqctl export_definitions <путь_к_файлу_определений>/definitions.file.json

В этом случае конечная точка (GET /api/definitions) используется напрямую, для экспорта определений всех виртуальных хостов, включенных в кластер:

curl -u {username}:{password} -X GET http://{hostname}:15672/api/definitions

7.5.4.2 Импорт определения

Внимание!

Избегайте импорта во время загрузки, если содержимое определения не изменилось! [1].

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

rabbitmqctl import_definitions <путь_к_файлу_определений>/definitions.file.json

Также, можно напрямую использовать конечную точку API (POST /api/definitions):

curl -u {username}:{password} -X POST -T <путь_к_файлу_определений>/definitions.file.json  http://{hostname}:15672/api/definitions

7.5.4.3 Резервное копирование сообщений

Перед резервным копированием сообщений, хранящихся на узле, его необходимо сначала остановить. В случае кластера с реплицированными очередями настоятельно рекомендуется остановить весь кластер на некоторое время, чтобы сделать резервную копию.

Если вместо этого один узел переполняется за раз, в очередях могут накапливаться дубликаты, точно так же, как при резервном копировании одного работающего узла.

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

Резервное копирование сообщений производится вручную; в настоящее время это – единственный способ резервного копирования сообщений.

Сообщения по умолчанию хранятся в директории /var/lib/rabbitmq/mnesia. Актуальный путь можно уточнить командой:

rabbitmq-diagnostics status | grep -A 2 -B 2 "Node data directory"

7.5.4.4 Восстановление (вручную) сообщений из резервной копии

Когда узел загружается, он вычисляет местоположение своего каталога данных и восстанавливает сообщения. Для восстановления сообщений брокер должен иметь все определения уже на месте.

Данные сообщений для неизвестных виртуальных хостов и очередей не будут загружены и могут быть удалены узлом. Поэтому при резервном копировании каталогов сообщений вручную важно убедиться, что определения уже доступны на целевом узле (тот, который подвергается восстановлению) – либо через импорт файла определения, либо путем резервного копирования всего каталога данных узла.

Если каталог данных узла был зарезервирован вручную (скопирован), то узел должен начинаться со всеми определениями и сообщениями. Нет необходимости сначала импортировать определения.

Сноски

[1]https://www.rabbitmq.com/definitions.html#import-on-boot-skip-if-unchanged