Como reinicio o rabbitmq após trocar de máquina?

Estou executando o django / aipo no EC2, com o rabbitmq como corretor. A máquina que eu estava usando falhou, então iniciei outra instância. Mas desde que mudei para a nova máquina, não consegui fazer o aipo funcionar.

EDIT: incluí muitos logs abaixo, para o caso de eu estar diagnosticando incorretamente o problema. Mas tenho 85% de certeza de que o problema é que o rabbitmq-server falha ao iniciar na fase "inicial do banco de dados".

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

Alguma idéia de como diagnosticar / resolver mais esse problema?

Aqui está o que acontece quando tento executar o aipo:

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

Rastreando-o, parece que o servidor rabbitmq é o problema e o banco de dados em 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==

Mas não consegui descobrir como reiniciar o 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 ()

Além disso, não sei se é relevante, mas esse processo está sendo executado em 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

Não consegui encontrar nenhuma documentação para esse tipo de falha. Alguma sugestão?

Eu recebi uma ajuda muito boa da lista rabbitmq-discuss:

O banco de dados que o RabbitMQ usa está vinculado ao nome do host da máquina, portanto, se você copiou o diretório do banco de dados para outra máquina, ele não funcionará. Se for esse o caso, você deverá configurar uma máquina com o mesmo nome de host de antes e transferir as mensagens pendentes para a nova máquina. Se não houver nada importante no rabbit, você pode limpar tudo removendo os arquivos RabbitMQ em / var / lib / rabbitmq.

Eu apaguei tudo em / var / lib / rabbitmq / mnesia / rabbit / e ele foi iniciado sem problemas. Viva!

O problema está relacionado ao fato de o Mnesia, que armazena a fila e a configuração de metadados do RabbitMQ, criar um banco de dados usando o nome do host da máquina.

Esses diretórios de banco de dados baseados em nome de host estarão localizados em:

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

Portanto, a opção de excluir os 2 diretórios acima e reiniciar o rabbitmq funcionará. Se o servidor rabbitmq foi migrado de um host para outro, você carregará o antigo banco de dados mnesia do nome do host. Simplesmente renomear o diretório para o nome correto do host não funcionará, de acordo com meus testes.

Portanto, caso você precise preservar a estrutura da fila , as contas de usuário e quaisquer outros metadados definidos para o seu servidor RabbitMQ, é necessário manter uma cópia desses metadados.

Há duas maneiras de extrair ou importar a configuração de metadados

• Plug-in de gerenciamento: ative o plug-in de gerenciamento do rabbitmq e acesse o servidor de URL: 15672. A página principal tem na parte inferior duas opções, uma para exportar e outra para importar a definição

• Linha de Comando: rabbitmqadmin export rabbit.config (ou import em vez de export)

Então, sugestões de resultados:

• mantenha uma exportação atual da sua estrutura de filas / usuários / etc
• ao migrar servidores ou passar pela recuperação, execute a ação para excluir a estrutura de diretórios anterior (se os dados na fila forem irrelevantes) e reimporte a configuração / metadados originais.
• Se algum dado enfileirado persistente for relevante, a melhor opção é renomear o nome do host do host recuperado para o original e permitir que as mensagens sejam processadas / desenfileiradas, é possível ajustar o nome do host novamente, se necessário.

Olá, tive uma situação semelhante ao migrar da Instância pequena para grande da AWS EC2 e precisava manter o RabbitMq em execução e trabalhar com arquivos de banco de dados de mnésia antigos em uma nova instância, pois eles continham muitas tarefas atrasadas importantes e informações da fila. Abaixo está a solução que eu costumava gerenciar isso. Talvez minha solução alternativa que permita não excluir a pasta mnesia e preservar dados possa ajudar alguém.

O principal problema é que sua nova máquina possui um novo nome de host - e o diretório recebe o nome dele (apenas renomear o diretório como mencionado anteriormente, não ajuda), portanto, precisamos renomear o nome do host da máquina e fazer o RabbitMq trabalhar com arquivos antigos. Seja "ip-0-0-0-0" o nome da máquina antiga (portanto, deve haver uma pasta de mnesia / ver / lib / rabbitmq / mnsesia / ip-0-0-0-0 ) e o novo nome do host da máquina é algo como "ip-1-1-1-1", mas o novo nome não importa, pois o substituiremos. Execute os seguintes comandos:

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

Após a reinicialização, sua máquina terá um novo nome e o RabbitMq deverá funcionar com arquivos antigos.