Como reinicio o rabbitmq após a troca de máquinas?

15

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

EDIT: Eu incluí um monte de logs abaixo, apenas no caso de eu estar diagnosticando errado o problema. Mas tenho 85% de certeza de que o problema é que o rabbitmq-server não inicia na fase de "inicialização 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 ideia de como diagnosticar / resolver ainda mais este problema?

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

De volta, 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?

    
por Abe 06.12.2011 / 02:42

3 respostas

15

Eu recebi uma ajuda muito boa da lista de discussões sobre o coelho:

The database RabbitMQ uses is bound to the machine's hostname, so if you copied the database dir to another machine, it won't work. If this is the case, you have to set up a machine with the same hostname as before and transfer any outstanding messages to the new machine. If there's nothing important in rabbit, you could just clear everything by removing the RabbitMQ files in /var/lib/rabbitmq.

Eu deletei tudo em / var / lib / rabbitmq / mnesia / rabbit / e ele começou sem problemas. Viva!

    
por 06.12.2011 / 18:55
8

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

Tais diretórios de bancos de dados baseados no nome do host estarão localizados em:

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

Assim, a opção de excluir os dois diretórios acima e reiniciar o rabbitmq funcionará. Se você tivesse o servidor rabbitmq migrado de um host para outro, você carregaria o banco de dados mnesia do nome do host anterior. Simplesmente renomear o diretório para o hostname correto irá 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 seu servidor RabbitMQ, será necessário manter uma cópia de tais metadados.

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

  • Plugin de gerenciamento: ative o plug-in de gerenciamento do rabbitmq e vá para 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 importar em vez de exportar)

Então, sugestões finais:

  • mantenha uma exportação atual de 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 enfileirados forem irrelevantes) e importe novamente a configuração original / metadados.
  • 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, e você poderá ajustar o nome do host novamente, se necessário.
por 06.06.2013 / 03:31
1

Oi, tive uma situação semelhante quando migrei da Instância Pequena para Grande do AWS EC2 e precisei manter o RabbitMq executando e trabalhando com arquivos antigos do banco de dados em nova instância, pois eles continham muitas tarefas atrasadas e informações de filas importantes. Abaixo está a solução que usei para gerenciar isso. Talvez minha solução alternativa que permita não excluir a pasta mnesia e preservar os dados possa ajudar alguém.

O problema principal é que sua nova máquina tem um novo nome de host - e o diretório é nomeado após ele (apenas renomeando o diretório como mencionado anteriormente, não ajuda) então precisamos renomear o nome do seu host e fazer o RabbitMq funcionar com arquivos antigos. Seja "ip-0-0-0-0" o antigo nome da máquina (então deve haver uma pasta mnesia / ver / lib / rabbitmq / mnsesia / ip-0-0-0-0 ) e novo host de máquina name é algo como "ip-1-1-1-1", mas o novo nome não importa, já que o sobrescrevemos. 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.

    
por 27.07.2014 / 10:47

Tags