web-dev-qa-db-ja.com

マシンの切り替え後にrabbitmqを再起動するにはどうすればよいですか？

EC2でDjango/celeryを実行しており、rabbitmqをブローカーとして使用しています。使っていたマシンが壊れたので、別のインスタンスを起動しました。しかし、新しいマシンに切り替えて以来、セロリを機能させることができませんでした。

編集：私が問題を誤って診断している場合に備えて、以下に多くのログを含めました。しかし、問題はrabbitmq-serverが「データベースの起動」フェーズで起動に失敗することであると85％確信しています。

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

この問題をさらに診断/解決する方法に関するアイデアはありますか？

セロリを実行しようとすると、次のようになります。

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

さかのぼってみると、rabbitmqサーバー、特にデータベースに問題があるようです。

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

しかし、私はサーバーを再起動する方法を理解することができませんでした：

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

また、それが関連しているかどうかはわかりませんが、このプロセスはバックグラウンドで実行されています。

$ 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

私はこの種の失敗に関するドキュメントを見つけることができませんでした。助言がありますか？

rabbitmq
16
Abe

私はrabbitmq-discussリストからいくつかの非常に良い助けを得ました：

RabbitMQが使用するデータベースはマシンのホスト名にバインドされているため、データベースディレクトリを別のマシンにコピーした場合は機能しません。この場合、以前と同じホスト名でマシンをセットアップし、未処理のメッセージを新しいマシンに転送する必要があります。 rabbitで何も重要でない場合は、/ var/lib/rabbitmqのRabbitMQファイルを削除するだけですべてをクリアできます。

/ var/lib/rabbitmq/mnesia/rabbit /のすべてを削除したところ、問題なく起動しました。やったー！

16
Abe

この問題は、RabbitMQのキューとメタデータ構成を格納するMnesiaがマシンのホスト名を使用してデータベースを作成するという事実に関連しています。

このようなホスト名ベースのデータベースディレクトリは、次の場所にあります。

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

したがって、上記の2つのディレクトリを削除してrabbitmqを再起動するオプションが機能します。 rabbitmqサーバーをホストから別のサーバーに移行した場合は、以前のホスト名mnesiaデータベースを保持します。私のテストによれば、ディレクトリの名前を正しいホスト名に変更するだけでnotが機能します。

したがって、キュー構造を保持する必要がある場合、ユーザーアカウント、およびRabbitMQサーバーに定義されているその他のメタデータの場合、そのようなメタデータのコピーを保持する必要があります。

メタデータ構成を抽出またはインポートするには2つの方法があります

  • 管理プラグイン：rabbitmqの管理プラグインをアクティブにし、url server：15672に移動します。メインページの下部には2つのオプションがあり、1つは定義をエクスポートするためのもので、もう1つは定義をインポートするためのものです。

  • コマンドライン：rabbitmqadmin export rabbit.config（またはexportの代わりにimport）

したがって、最終的な提案：

  • キュー構造/ユーザー/その他の現在のエクスポートを保持する
  • サーバーを移行するとき、またはリカバリを実行するときに、以前のディレクトリ構造を削除するアクションを実行し（キューに入れられたデータが関係ない場合）、元の構成/メタデータを再インポートします。
  • 永続的なキューに入れられたデータが関連する場合、最善のオプションは、回復したホストのホスト名を元の名前に変更し、メッセージを処理/デキューできるようにすることです。その後、必要に応じてホスト名を再度調整できます。
8
gextra

こんにちは私はAWS EC2の小さなインスタンスから大きなインスタンスに移行したときに同様の状況にあり、RabbitMqを実行し続け、新しいインスタンスで古いmnesia DBファイルを操作する必要がありました。以下は、これを管理するために使用した回避策です。おそらく、mnesiaフォルダーを削除せずにデータを保持できるようにする私の回避策は、誰かを助けることができます。

主な問題は、新しいマシンに新しいホスト名が付けられることであり、ディレクトリにはその名前が付けられます（前述のようにディレクトリの名前を変更するだけでは役に立たないため）。 "ip-0-0-0-0"を古いマシン名にします（mnesiaフォルダーがあるはずです/ ver/lib/rabbitmq/mnsesia/ip-0-0-0-） 、および新しいマシンのホスト名は「ip-1-1-1-1」のようなものですが、新しい名前は上書きするため重要ではありません。次のコマンドを実行します。

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

再起動後、マシンは新しい名前になり、RabbitMqは古いファイルで動作するはずです。

1
Dmytriy Voloshyn