Вопрос или проблема
У меня есть виртуальная машина Oracle Linux 9.4 с установленным RabbitMQ 3.13.7 и Erlang 26.2.5.4 (не могу обновить до RabbitMQ 4, так как наше приложение не поддерживает его). Я пытаюсь создать несколько политик, но получаю сообщение об ошибке в одной из наших сред:
Ошибка проверки
Классические зеркальные очереди устарели.
Их использование не разрешено по конфигурации (переопределяется значение по умолчанию, которое разрешено):
“deprecated_features.permit.classic_queue_mirroring = false”
По умолчанию их использование не будет разрешено в следующей минорной версии RabbitMQ (если таковая будет), и они будут удалены в RabbitMQ 4.0.0.
Чтобы продолжить использование классических зеркальных очередей, когда они не разрешены по умолчанию, установите следующий параметр в вашей конфигурации:
“deprecated_features.permit.classic_queue_mirroring = true”
Проблема в том, что я никогда не касался этого значения конфигурации. Я могу создавать политики на наших средах TST и PROD с такой же ОС, версиями RabbitMQ и Erlang, но не на UAT. Все среды были установлены с использованием Ansible playbooks, и одинаковые значения конфигурации были изменены во всех из них (я даже diff
сравнил файлы, чтобы убедиться).
Естественно, я попробовал то, что предлагает сообщение об ошибке, и добавил deprecated_features.permit.classic_queue_mirroring = true
в /etc/rabbitmq/rabbitmq.conf, но это не помогло. Я проверил, что RabbitMQ использует этот файл конфигурации.
Я также попытался динамически включить это с помощью rabbitmqctl eval 'application:set_env(rabbit, deprecated_features, #{permit => [classic_queue_mirroring]}).'
Если я выполняю rabbitmqctl eval 'application:get_env(rabbit, deprecated_features).'
, я получаю {ok,#{permit => [classic_queue_mirroring]}}
, что означает, что функция включена, но я все равно получаю то же сообщение об ошибке при попытке создать политику.
В чем может быть причина этого? Почему RabbitMQ говорит, что использование этой функции не разрешено по конфигурации, когда это не так?
Ответ или решение
Проблема, с которой вы столкнулись в процессе создания политик в RabbitMQ 3.13.7, связана с использованием устаревших очередей с зеркалированием, которые официально больше не поддерживаются и по умолчанию запрещены в конфигурации RabbitMQ. Хотя, как утверждаете вы, данное ограничение не должно применяться, поскольку вы внесли соответствующие изменения в конфигурацию. Рассмотрим подробно данный вопрос, чтобы найти возможное решение.
Теория
RabbitMQ, начиная с версий ближе к 4.0.0, постепенно отказывается от поддержки классических очередей с зеркалированием. Эта функциональность отмечена как устаревшая из-за множества вопросов производительности и надежности, возникших в течение времени. Начиная с версии 3.13.7, использование таких очередей по умолчанию запрещено, если явно не разрешено в конфигурации через параметр deprecated_features.permit.classic_queue_mirroring
.
Тем не менее, если ваше приложение всё ещё требует использования классических зеркалируемых очередей, можно временно включить их, добавив параметры разрешения в конфигурационные файлы RabbitMQ или используя динамическую конфигурацию.
Пример
Вы описали ситуацию, в которой вы изменили конфигурационные файлы в UAT-среде, добавив строчку:
deprecated_features.permit.classic_queue_mirroring = true
Кроме изменения конфигурационного файла, вы также попытались применить динамическую команду через rabbitmqctl
для временного разрешения функции:
rabbitmqctl eval 'application:set_env(rabbit, deprecated_features, #{permit => [classic_queue_mirroring]}).'
Несмотря на успешное изменение конфигурации, вы получаете ту же ошибку при попытке создания политики, указывающей, что использование классических зеркалируемых очередей не разрешено.
Применение
Основываясь на описанном контексте, давайте исследуем возможные причины продолжающейся проблемы и пути её решения:
-
Перезагрузка Настроек RabbitMQ: После изменения конфигурационных файлов, убедитесь, что сервис RabbitMQ был корректно перезапущен для применения новых настроек. Вы можете использовать следующие команды для перезапуска сервиса:
sudo systemctl restart rabbitmq-server
Также, проверьте статус службы, чтобы подтвердить, что она запустилась без ошибок:
sudo systemctl status rabbitmq-server
-
Проверка Конфигурационного Пути: Убедитесь, что RabbitMQ действительно использует изменённый конфигурационный файл. Для этого можно выполнить команду:
rabbitmqctl environment
Проверьте вывод на наличие пути к корректному
rabbitmq.conf
, который содержит ваши изменения. -
Кэш Конфигурации: Некоторые изменения могут не применяться из-за кеширования старой конфигурации. Попробуйте полностью остановить RabbitMQ и перед повторным запуском удостовериться, что все старые процессы и кеши очищены.
-
Логи и Диагностика: Проверьте лог-файлы RabbitMQ на наличие дополнительной информации или предупреждений, которые могут указать на причину проблемы. Логи обычно можно найти в директории
/var/log/rabbitmq/
. -
Верификация Консистентности Среды: Несмотря на уверенность в идентичности окружений (UAT, TST, PROD), повторно проверьте установленные пакеты и зависимости, включая версии библиотек Erlang, чтобы исключить маловероятные деструктивные различия.
-
DevOps-Процессы и Ansible: Поскольку вы используете Ansible для развертывания, удостоверьтесь, что плейбуки для всех сред синхронизированы и обновлены для отражения всех внесённых конфигурационных изменений.
-
Пользовательские Права и Разрешения: Также стоит убедиться, что конфигурационные права доступа не блокируют чтение или применение изменений файла конфигурации RabbitMQ.
Если ни один из этих шагов не решит проблему, рассмотрите возможность обновления вашей программы до версии RabbitMQ 4.0.0 или выше. В этом случае также возможно будет облегчить процесс интеграции посредством использования стандартных кластерных очередей, которые теперь номинальные в RabbitMQ, заменив устаревшие классические зеркалируемые очереди.
Конечная цель заключается в адаптации вашей системы соответственно изменениям программного обеспечения, обеспечивая при этом бесперебойную работу приложения.