Comment redémarrer rabbitmq après avoir changé de machine?

16

J'utilise django / celery sur EC2, avec rabbitmq comme courtier. La machine que j'utilisais a échoué, j'ai donc lancé une autre instance. Mais depuis que je suis passé à la nouvelle machine, je n'ai pas réussi à faire fonctionner le céleri.

EDIT: J'ai inclus beaucoup de journaux ci-dessous, juste au cas où je diagnostiquerais mal le problème. Mais je suis sûr à 85% que le problème est que rabbitmq-server ne démarre pas dans la phase de "base de données de démarrage".

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

Avez-vous des idées sur la façon de diagnostiquer / résoudre ce problème?

Voici ce qui se passe lorsque j'essaie d'exécuter du céleri:

$ 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...

En remontant, il semble que le serveur rabbitmq soit le problème, et la base de données en particulier:

$ 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==

Mais je n'ai pas pu comprendre comment redémarrer le serveur:

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 ()

Aussi, je ne sais pas si c'est pertinent, mais ce processus s'exécute en arrière-plan.

$ 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

Je n'ai pas pu trouver de documentation pour ce type d'échec. Aucune suggestion?

Abe
la source

Réponses:

16

J'ai obtenu une très bonne aide de la liste rabbitmq-discuter:

La base de données utilisée par RabbitMQ est liée au nom d'hôte de la machine, donc si vous avez copié le répertoire de la base de données sur une autre machine, cela ne fonctionnera pas. Si tel est le cas, vous devez configurer une machine avec le même nom d'hôte qu'auparavant et transférer tous les messages en attente vers la nouvelle machine. S'il n'y a rien d'important dans rabbit, vous pouvez tout effacer en supprimant les fichiers RabbitMQ dans / var / lib / rabbitmq.

J'ai tout supprimé dans / var / lib / rabbitmq / mnesia / rabbit / et cela a démarré sans problème. Hourra!

Abe
la source
8

Le problème est lié au fait que Mnesia, qui stocke la file d'attente et la configuration des métadonnées de RabbitMQ, crée une base de données en utilisant le nom d'hôte de la machine.

Ces répertoires de base de données basés sur le nom d'hôte seront situés sous:

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

Ainsi, l'option pour supprimer les 2 répertoires ci-dessus et redémarrer rabbitmq fonctionnera. Si vous avez fait migrer le serveur rabbitmq d'un hôte à un autre, vous porterez l'ancienne base de données mnesia du nom d'hôte. Renommer simplement le répertoire au bon nom d'hôte ne fonctionnera pas , selon mes tests.

Donc, si vous devez conserver la structure de la file d'attente , les comptes d'utilisateurs et toutes les autres métadonnées définies pour votre serveur RabbitMQ, vous devez conserver une copie de ces métadonnées.

Il existe deux façons d'extraire ou d'importer la configuration des métadonnées

  • Plugin de gestion: activez le plugin de gestion de rabbitmq et accédez au serveur url: 15672. La page principale a en bas deux options, une pour exporter et une pour importer la définition

  • Ligne de commande: rabbitmqadmin export rabbit.config (ou import au lieu d'export)

Donc, des suggestions de résultat:

  • garder une exportation actuelle de votre structure de file d'attente / utilisateurs / etc
  • lors de la migration des serveurs ou de la récupération, effectuez l'action pour supprimer l'ancienne structure de répertoires (si les données en file d'attente ne sont pas pertinentes) et réimportez la configuration / métadonnées d'origine.
  • Si des données en file d'attente persistantes sont pertinentes, la meilleure option est de renommer le nom d'hôte de votre hôte récupéré en celui d'origine et de permettre aux messages de traiter / retirer la file d'attente, vous pouvez alors ajuster à nouveau le nom d'hôte si nécessaire.
gextra
la source
1

Salut, j'ai eu une situation similaire lorsque j'ai migré d'AWS EC2 Small vers Large Instance et que je devais continuer à exécuter RabbitMq et à travailler avec les anciens fichiers DB mnesia sur la nouvelle instance car ils contenaient beaucoup de tâches retardées importantes et d'informations sur la file d'attente. Voici une solution de contournement que j'ai utilisée pour gérer cela. Peut-être que ma solution de contournement qui permet de ne pas supprimer le dossier mnesia et de conserver les données peut aider quelqu'un.

Le principal problème est que votre nouvelle machine a un nouveau nom d'hôte - et le répertoire porte son nom (renommer simplement le répertoire comme mentionné précédemment, n'aide pas), nous devons donc renommer le nom d'hôte de votre machine et faire en sorte que RabbitMq fonctionne avec les anciens fichiers. Soit "ip-0-0-0-0" l'ancien nom de la machine (il devrait donc y avoir un dossier mnesia / ver / lib / rabbitmq / mnsesia / ip-0-0-0-0 ), et le nouveau nom d'hôte de la machine est quelque chose comme "ip-1-1-1-1", mais le nouveau nom n'a pas d'importance car nous allons l'écraser. Exécutez les commandes suivantes:

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

Après le redémarrage, votre machine aura un nouveau nom et RabbitMq devrait fonctionner avec les anciens fichiers.

Dmytriy Voloshyn
la source