¿Cómo reinicio rabbitmq después de cambiar de máquina?

Estoy ejecutando django / celery en EC2, con rabbitmq como el corredor. La máquina que estaba usando falló, así que encendí otra instancia. Pero desde que cambié a la nueva máquina, no he podido hacer que el apio funcione.

EDITAR: He incluido muchos registros a continuación, en caso de que esté diagnosticando mal el problema. Pero estoy 85% seguro de que el problema es que rabbitmq-server no se inicia en la fase de "inicio de la base de datos".

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

¿Alguna idea sobre cómo diagnosticar / resolver este problema?

Esto es lo que sucede cuando intento correr apio:

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

Al rastrearlo, parece que el servidor rabbitmq es el problema, y ​​la base de datos en particular:

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

Pero no he podido descubrir cómo reiniciar el servidor:

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

Además, no sé si es relevante, pero este proceso se está ejecutando en segundo plano.

$ 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

No he podido encontrar ninguna documentación para este tipo de falla. ¿Alguna sugerencia?

Obtuve una muy buena ayuda de la lista rabbitmq-debate:

La base de datos que utiliza RabbitMQ está vinculada al nombre de host de la máquina, por lo que si copió el directorio de la base de datos a otra máquina, no funcionará. Si este es el caso, debe configurar una máquina con el mismo nombre de host que antes y transferir los mensajes pendientes a la nueva máquina. Si no hay nada importante en el conejo, puede borrar todo eliminando los archivos RabbitMQ en / var / lib / rabbitmq.

Eliminé todo en / var / lib / rabbitmq / mnesia / rabbit / y comenzó sin problemas. ¡Hurra!

El problema está relacionado con el hecho de que Mnesia, que almacena la configuración de cola y metadatos de RabbitMQ, crea una base de datos utilizando el nombre de host de la máquina.

Tales directorios de bases de datos basados ​​en nombres de host se ubicarán en:

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

Entonces, la opción para eliminar los 2 directorios anteriores y reiniciar rabbitmq funcionará. Si ha migrado el servidor rabbitmq de un host a otro, llevará la antigua base de datos mnesia de hostname. Simplemente cambiar el nombre del directorio al nombre de host correcto no funcionará, de acuerdo con mis pruebas.

Por lo tanto, en caso de que necesite preservar la estructura de la cola , las cuentas de usuario y cualquier otro metadato definido para su servidor RabbitMQ, debe conservar una copia de dichos metadatos.

Hay dos formas de extraer o importar la configuración de metadatos

• Complemento de gestión: active el complemento de gestión de rabbitmq y vaya al servidor de URL: 15672. La página principal tiene en la parte inferior dos opciones, una para exportar y otra para importar la definición.

• Línea de comando: rabbitmqadmin export rabbit.config (o importar en lugar de exportar)

Entonces, sugerencias de resultados:

• mantener una exportación actual de su estructura de cola / usuarios / etc.
• al migrar servidores, o al pasar por la recuperación, tome la acción de eliminar la estructura de directorio anterior (si los datos en cola son irrelevantes) y vuelva a importar la configuración / metadatos originales.
• Si los datos en cola persistentes son relevantes, la mejor opción es renombrar el nombre de host de su host recuperado al original y permitir que los mensajes se procesen / retiren, entonces puede ajustar el nombre de host nuevamente si es necesario.

Hola, tuve una situación similar cuando migré de AWS EC2 Small a Large Instance y necesitaba mantener RabbitMq ejecutándose y trabajando con archivos antiguos de mnesia DB en una nueva instancia, ya que contenían muchas tareas importantes e información de cola. A continuación se muestra la solución que usé para administrar esto. Quizás mi solución alternativa que le permite a uno no eliminar la carpeta mnesia y preservar los datos puede ayudar a alguien.

El problema principal es que su nueva máquina tiene un nuevo nombre de host, y el directorio lleva su nombre (simplemente renombrar el directorio como se mencionó anteriormente, no ayuda), por lo que debemos cambiar el nombre de su máquina y hacer que RabbitMq funcione con archivos antiguos. Deje que "ip-0-0-0-0" sea el nombre antiguo de la máquina (por lo que debe haber una carpeta mnesia / ver / lib / rabbitmq / mnsesia / ip-0-0-0-0 ), y el nuevo nombre de host de la máquina es algo así como "ip-1-1-1-1", pero el nuevo nombre no importa ya que lo sobrescribiremos. Ejecute los siguientes comandos:

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

Después de reiniciar su máquina tendrá un nuevo nombre y RabbitMq debería funcionar con archivos antiguos.