Как исправить эту ошибку rabbitmq/сельдерея?

Question

Итак, я использую сельдерей на нескольких серверах с кластерным backbit. В последнее время, все, что я делаю с сельдереем начала висит на неопределенный срок, и проверять журналы для RabbitMQ дает мне с этим неясным сообщением об ошибке:

=ERROR REPORT==== 20-Mar-2013::23:52:25 === 
connection <0.15823.3>, channel 1 - soft error: 
{amqp_error,not_found, 
     "no binding i-69995906 between exchange 'i-69995906' in vhost 'celery' and queue 'i-69995906' in vhost 'celery'", 
     'queue.bind'} 

Запуск rabbitmqctl list_bindings дает мне это:

# rabbitmqctl list_bindings -p celery 
Listing bindings ... 
     exchange celery queue celery [] 
celery exchange celery queue celery [] 
...done. 

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

Answer 1

Спасибо за вопрос. Я оказался в том же месте.

я был в состоянии исправить эту проблему, удалив виртуальный хост и воссоздавать его

rabbitmqctl delete_vhost celery 
rabbitmqctl add_vhost celery 
rabbitmqctl set_permissions -p celery <user> ".*" ".*" ".*" 

Answer 2

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

Предисловие: Мы сделали опыт некоторых разделов раньше и не смогли подтолкнуть к одной очереди, а также не смогли воссоздать связывание и получили ту же ошибку, как вы.

Остановка и запуск по одному не работают. Ошибка остается, и я предполагаю, что какой-то узел кластера сделал кеширование чего-то ошибочного ip/config.

Обнаружение: Хороший способ определить, если это вы ошибки работает rabbitmqctl list_queues на всех узлах. Если узлы показывают разные очереди, что-то пошло не так.

Решение: Как заявлено, решение заключалось в том, чтобы остановить все серверы кроликов в течение нескольких секунд, чтобы не было «кеша». Конечно, это только ваше решение не зависит от постоянных очередей.

Answer 3

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

У меня была очередь с тремя ключами маршрутизации, связанными в кластере. Мне пришлось удалить очередь, пока один из узлов не был опущен, и после этого я всегда получал ошибку «отсутствие привязки между обменом в vhost и queue» при попытке зарегистрировать ключи маршрутизации снова во вновь созданной очереди с тем же именем.

оригинальная очередь была создана как «Durable», и решение было:

• Удалить очередь
• Создать новую очередь с тем же именем, но «транзиторной» (недлительным)
• Зарегистрируйте исходные 3 ключа маршрутизации в очереди. Это остановило повышение ошибок.

Поскольку я хотел иметь прочную очередь, я снова удалил очередь, создал новую «Durable» очередь с тем же именем, а затем привязал ключи маршрутизации, работающие отлично.

Возможно, создав новую очередь с другим типом «Долговечность», сбросил старые привязки, которые все еще остались где-то.