Wie starte ich rabbitmq neu, nachdem ich die Maschine gewechselt habe?


15

Ich verwende Django / Sellerie auf EC2 mit Rabbitmq als Broker. Der Computer, den ich verwendet habe, ist ausgefallen, daher habe ich eine andere Instanz gestartet. Aber seit ich auf die neue Maschine umgestiegen bin, konnte ich keinen Sellerie mehr zum Laufen bringen.

EDIT: Ich habe viele Protokolle unten aufgenommen, nur für den Fall, dass ich das Problem falsch diagnostiziere. Aber ich bin mir zu 85% sicher, dass das Problem darin besteht, dass der rabbitmq-Server in der Phase "Datenbank starten" nicht gestartet werden kann.

node          : rabbit@ip-10-212-66-181
app descriptor: /usr/lib/rabbitmq/lib/rabbitmq_server-1.7.2/sbin/../ebin/rabbit.app
home dir      : /var/lib/rabbitmq
cookie hash   : 5+uQ077En5bpvle3HJCQMg==
log           : /var/log/rabbitmq/rabbit.log
sasl log      : /var/log/rabbitmq/rabbit-sasl.log
database dir  : /var/lib/rabbitmq/mnesia/rabbit

starting internal event notification system                           ...done
starting logging server                                               ...done
starting database                                                     ...Erlang has closed

Irgendwelche Ideen zur weiteren Diagnose / Lösung dieses Problems?

Folgendes passiert, wenn ich versuche, Sellerie zu produzieren:

$ python manage.py celeryd -l info
/opt/bitnami/python/lib/python2.6/site-packages/django_celery-2.4.2-py2.6.egg/djcelery/loaders.py:86: UserWarning: Using settings.DEBUG leads to a memory leak, never use this setting in production environments!
  warnings.warn("Using settings.DEBUG leads to a memory leak, never "
[2011-12-05 19:40:13,545: WARNING/MainProcess]  

 -------------- celery@ip-10-212-66-181 v2.4.3
---- **** -----
--- * ***  * -- [Configuration]
-- * - **** ---   . broker:      amqp://guest@localhost:5672//
- ** ----------   . loader:      djcelery.loaders.DjangoLoader
- ** ----------   . logfile:     [stderr]@INFO
- ** ----------   . concurrency: 1
- ** ----------   . events:      OFF
- *** --- * ---   . beat:        OFF
-- ******* ----
--- ***** ----- [Queues]
 --------------   . celery:      exchange:celery (direct) binding:celery


[Tasks]
  . tbAnalytics.models.processAnalysis
  . tbCollections.models.processCollection

[2011-12-05 19:40:13,558: INFO/PoolWorker-1] child process calling self.run()
[2011-12-05 19:40:13,562: WARNING/MainProcess] celery@ip-10-212-66-181 has started.
[2011-12-05 19:40:13,564: ERROR/MainProcess] Consumer: Connection Error: [Errno 111] Connection refused. Trying again in 2 seconds...
[2011-12-05 19:40:15,574: ERROR/MainProcess] Consumer: Connection Error: [Errno 111] Connection refused. Trying again in 4 seconds...

Wenn man es zurückverfolgt, sieht es so aus, als wäre der rabbitmq-Server das Problem und insbesondere die Datenbank:

$ sudo rabbitmqctl status
Status of node 'rabbit@ip-10-212-66-181' ...
Error: unable to connect to node 'rabbit@ip-10-212-66-181': nodedown
diagnostics:
- nodes and their ports on ip-10-212-66-181: [{rabbitmqctl14448,38289}]
- current node: 'rabbitmqctl14448@ip-10-212-66-181'
- current node home dir: /var/lib/rabbitmq
- current node cookie hash: 5+uQ077En5bpvle3HJCQMg==

Es ist mir jedoch nicht gelungen, den Server neu zu starten:

bitnami@ip-10-212-66-181:/var/log/rabbitmq$ sudo rabbitmq-server start_app

+---+   +---+
|   |   |   |
|   |   |   |
|   |   |   |
|   +---+   +-------+
|                   |
| RabbitMQ  +---+   |
|           |   |   |
|   v1.7.2  +---+   |
|                   |
+-------------------+
AMQP 8-0
Copyright (C) 2007-2010 LShift Ltd., Cohesive Financial Technologies LLC., and Rabbit Technologies Ltd.
Licensed under the MPL.  See http://www.rabbitmq.com/

node          : rabbit@ip-10-212-66-181
app descriptor: /usr/lib/rabbitmq/lib/rabbitmq_server-1.7.2/sbin/../ebin/rabbit.app
home dir      : /var/lib/rabbitmq
cookie hash   : 5+uQ077En5bpvle3HJCQMg==
log           : /var/log/rabbitmq/rabbit.log
sasl log      : /var/log/rabbitmq/rabbit-sasl.log
database dir  : /var/lib/rabbitmq/mnesia/rabbit

starting internal event notification system                           ...done
starting logging server                                               ...done
starting database                                                     ...Erlang has closed
{"init terminating in do_boot",{{nocatch,{error,{cannot_start_application,rabbit,{bad_return,{{rabbit,start,[normal,[]]},{'EXIT',{{case_clause,{error,{timeout_waiting_for_tables,[rabbit_user,rabbit_user_permission,rabbit_vhost,rabbit_config,rabbit_listener,rabbit_durable_route,rabbit_route,rabbit_reverse_route,rabbit_durable_exchange,rabbit_exchange,rabbit_durable_queue,rabbit_queue]}}},[{rabbit,'-run_boot_step/1-lc$^1/1-1-',1},{rabbit,run_boot_step,1},{rabbit,'-start/2-lc$^0/1-0-',1},{rabbit,start,2},{application_master,start_it_old,4}]}}}}}}},[{init,start_it,1},{init,start_em,1}]}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()

Weiß auch nicht, ob es relevant ist, aber dieser Prozess läuft im Hintergrund.

$ ps aux | grep rabbit
rabbitmq   714  0.0  0.0   1980   408 ?        S    Dec04   0:00 /usr/lib/erlang/erts-5.7.4/bin/epmd -daemon

Ich konnte keine Dokumentation für diese Art von Fehler finden. Irgendwelche Vorschläge?

Antworten:


15

Ich habe einige sehr gute Hilfe von der RabbitMQ-Diskussionsliste bekommen:

Die von RabbitMQ verwendete Datenbank ist an den Hostnamen des Computers gebunden. Wenn Sie also das Datenbankverzeichnis auf einen anderen Computer kopiert haben, funktioniert dies nicht. In diesem Fall müssen Sie einen Computer mit demselben Hostnamen wie zuvor einrichten und alle ausstehenden Nachrichten auf den neuen Computer übertragen. Wenn Kaninchen nichts Wichtiges enthält, können Sie einfach alles löschen, indem Sie die RabbitMQ-Dateien in / var / lib / rabbitmq entfernen.

Ich habe alles in / var / lib / rabbitmq / mnesia / rabbit / gelöscht und es lief ohne Probleme an. Hurra!


8

Das Problem hängt mit der Tatsache zusammen, dass Mnesia, das die Warteschlangen- und Metadatenkonfiguration von RabbitMQ speichert, eine Datenbank unter Verwendung des Hostnamens des Computers erstellt.

Solche hostnamenbasierten Datenbankverzeichnisse befinden sich unter:

<rabbitmq_installdir>/var/lib/rabbitmq/mnesia/rabbit@<yourhostname>
<rabbitmq_installdir>/var/lib/rabbitmq/mnesia/rabbit@<yourhostname>-plugins-expanded

Die Option, die obigen 2 Verzeichnisse zu löschen und rabbitmq neu zu starten, funktioniert also. Wenn Sie den rabbitmq-Server von einem Host auf einen anderen migriert haben, werden Sie die frühere Hostnamen-Mnesia-Datenbank führen. Laut meinen Tests funktioniert es nicht , das Verzeichnis einfach in den richtigen Hostnamen umzubenennen.

Wenn Sie also die Warteschlangenstruktur , Benutzerkonten und andere für Ihren RabbitMQ-Server definierte Metadaten beibehalten möchten, müssen Sie eine Kopie dieser Metadaten aufbewahren.

Es gibt zwei Möglichkeiten, die Metadatenkonfiguration zu extrahieren oder zu importieren

  • Management Plugin: Aktiviere das Management Plugin von rabbitmq und gehe zum URL Server: 15672. Die Hauptseite hat im unteren Bereich zwei Optionen, eine zum Exportieren und eine zum Importieren der Definition

  • Befehlszeile: rabbitmqadmin export rabbit.config (oder importieren statt exportieren)

Unterm Strich also Vorschläge:

  • Behalten Sie einen aktuellen Export Ihrer Warteschlangenstruktur / users / etc
  • Wenn Sie Server migrieren oder eine Wiederherstellung durchführen, löschen Sie die vorherige Verzeichnisstruktur (falls die in der Warteschlange befindlichen Daten irrelevant sind) und importieren Sie die ursprünglichen Konfigurations- / Metadaten erneut.
  • Wenn persistente Daten in der Warteschlange relevant sind, können Sie den Hostnamen Ihres wiederhergestellten Hosts am besten in den ursprünglichen Hostnamen umbenennen und zulassen, dass die Nachrichten verarbeitet / aus der Warteschlange entfernt werden. Anschließend können Sie den Hostnamen bei Bedarf erneut anpassen.

1

Hallo, ich hatte eine ähnliche Situation, als ich von AWS EC2 Small zu Large Instance migrierte und RabbitMq am Laufen halten und mit alten Mnesia-DB-Dateien auf einer neuen Instanz arbeiten musste, da sie viele wichtige verzögerte Aufgaben und Warteschlangeninformationen enthielten. Unten finden Sie eine Problemumgehung, die ich verwendet habe, um dies zu verwalten. Vielleicht kann meine Problemumgehung, die es einem ermöglicht, Mnesia-Ordner nicht zu löschen und Daten zu bewahren, jemandem helfen.

Das Hauptproblem ist, dass Ihr neuer Rechner einen neuen Hostnamen hat - und das Verzeichnis danach benannt ist (nur das Umbenennen des Verzeichnisses, wie oben erwähnt, hilft nicht), sodass wir Ihren Rechner-Hostnamen umbenennen und RabbitMq mit alten Dateien arbeiten lassen müssen. "Ip-0-0-0-0" soll ein alter Rechnername sein (also sollte es einen Mnesia-Ordner / ver / lib / rabbitmq / mnsesia / ip-0-0-0-0 geben ), und der neue Rechnername lautet So etwas wie "ip-1-1-1-1", aber der neue Name spielt keine Rolle, da wir ihn überschreiben werden. Führen Sie folgende Befehle aus:

sudo -s
echo "127.0.0.1 ip-0-0-0-0" >> /etc/hosts 
echo "ip-0-0-0-0" > /etc/hostname
reboot

Nach dem Neustart hat Ihr Computer einen neuen Namen und RabbitMq sollte mit alten Dateien funktionieren.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.