rabbitmq no_running_cluster_nodes 问题解决

配置rabbitmq集群的时候出现如下问题。
搞了好久都没发现问题出在哪,google了好久也没找出答案,最后看了几个博文之后最终发现了问题。

原因:stop_app之后,erl的进程依然存在,所以要把这个进程杀掉。

解决办法:ps -ef|grep erl,列出来的所有进程都杀掉,然后按照cluster配置方法配置即可。

几个前提条件:要配置集群的所有机器上的 ~/.erlang.cookie 的内容保持一样。

<code>Clustering node rabbit@HostName2 with [rabbit@HostName1] ...
Error: {no_running_cluster_nodes,[rabbit@HostName1],
                                 [rabbit@HostName1]}</code>

参考文章:

http://www.rabbitmq.com/clustering.html#setup

http://www.erlang.org/doc/reference_manual/distributed.html

http://guibin.iteye.com/blog/935033

http://www.cnblogs.com/me-sa/archive/2012/11/12/2766700.html

最后附上一个教程博文:

Clustering overview

A RabbitMQ broker is a logical grouping of one or several Erlang nodes, each running the RabbitMQ application and sharing users, virtual hosts, queues, exchanges, etc. Sometimes we refer to the collection of nodes as a cluster.

All data/state required for the operation of a RabbitMQ broker is replicated across all nodes, for reliability and scaling, with full ACID properties. An exception to this are message queues, which currently only reside on the node that created them, though they are visible and reachable from all nodes. Future releases of RabbitMQ will introduce migration and replication of message queues.

The easiest way to set up a cluster is by auto configuration using a default cluster config file. See the clustering transcripts for an example.

The composition of a cluster can be altered dynamically. All RabbitMQ brokers start out as running on a single node. These nodes can be joined into clusters, and subsequently turned back into individual brokers again.

RabbitMQ brokers tolerate the failure of individual nodes. Nodes can be started and stopped at will.

A node can be a RAM node or a disk node. RAM nodes keep their state only in memory (with the exception of the persistent contents of durable queues which are still stored safely on disc). Disk nodes keep state in memory and on disk. As RAM nodes don’t have to write to disk as much as disk nodes, they can perform better. Because state is replicated across all nodes in the cluster, it is sufficient to have just one disk node within a cluster, to store the state of the cluster safely. Beware, however, that RabbitMQ will not stop you from creating a cluster with only RAM nodes. Should you do this, and suffer a power failure to the entire cluster, the entire state of the cluster, including all messages, will be lost.

Clustering transcript

The following is a transcript of setting up and manipulating a RabbitMQ cluster across three machines - rabbit1, rabbit2, rabbit3, with two of the machines replicating data on ram and disk, and the other replicating data in ram only.

We assume that the user is logged into all three machines, that RabbitMQ has been installed on the machines, and that the rabbitmq-server and rabbitmqctl scripts are in the user’s PATH.

Initial setup

Erlang nodes use a cookie to determine whether they are allowed to communicate with each other – for two nodes to be able to communicate they must have the same cookie.

The cookie is just a string of alphanumeric characters. It can be as long or short as you like.

Erlang will automatically create a random cookie file when the RabbitMQ server starts up. This will be typically located in /var/lib/rabbitmq/.erlang.cookie on Unix systems and C:\Documents and Settings\Current User\Application Data\RabbitMQ\.erlang.cookie on Windows systems. The easiest way to proceed is to allow one node to create the file, and then copy it to all the other nodes in the cluster.

As an alternative, you can insert the option “-setcookie cookie” in the erl call in the rabbitmq-server and rabbitmqctl scripts.

Starting independent nodes

Clusters are set up by re-configuring existing RabbitMQ nodes into a cluster configuration. Hence the first step is to start RabbitMQ on all nodes in the normal way:

rabbit1$ <i>rabbitmq-server -detached</i>
rabbit2$ <i>rabbitmq-server -detached</i>
rabbit3$ <i>rabbitmq-server -detached</i>

This creates three independent RabbitMQ brokers, one on each node, as confirmed by the cluster_status command:

rabbit1$ <i>rabbitmqctl cluster_status</i>
Status of node rabbit@rabbit1 ...
[...,
 {nodes,[{disc,[rabbit@rabbit1]}]},
 {running_nodes,[rabbit@rabbit1]}]
...done.
rabbit2$ <i>rabbitmqctl cluster_status</i>
Status of node rabbit@rabbit2 ...
[...,
 {nodes,[{disc