[rabbitmq-discuss] Disk node vs ram node

Thu Aug 5 21:49:51 BST 2010

Thanks for your response Alex, 

1. So if I start node A by itself, and then cluster B against A, then A becomes a disk node because I specified A in the rabbitmqctl command? Here are the steps

Node1: 
start_app
add_vhost host1
add_user user pass

Node2:
stop_app
reset
cluster node1 <--- (is this the step that makes node A a disk node?)
start_app

Node3:
stop_app
reset
cluster node1 
start_app

2. To be clear, if I send a message that creates the queue Q1 in node A in a cluster with node A, node B, and node C and node A goes down, then I will lose those messages on node A. Node A is down, but B and C should still be alive. If I send the same message to be queued on Q1, will Q1 be created on node B and node C? For me so far, that is not the case. When I send a message to be queued on Q1 (where the messages on Q1 on node A are now lost because node A is down) I do not see the queue getting created on either node B or node C. Is there something wrong with my steps?

3. I am using RabbitMQ 1.7.2. Just to be clear there is _no way_ on 1.7.2 to determine whether or not a node is a disk node or ram node? 

-----Original Message-----
From: Alexandru Scvorţov [mailto:scvalex at gmail.com] On Behalf Of Alexandru Scvortov
Sent: Thursday, August 05, 2010 12:43 PM
To: Vince Chang
Cc: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] Disk node vs ram node

> 1.  Assuming I have 3 nodes, node A, B, and C. Does node A become a disk
> node by default when I set up the vhosts/users/permissions?

The disk nodes are the ones explicitly listed in the "rabbitmqctl
cluster" command.

So,
% rabbitmqctl cluster rabbit at A rabbit at B
results in a cluster where A and B are disk nodes.  If that command is
run on either A or B,  the cluster has just the two nodes.
If, on the other hand, that command is run on C, you get a cluster with
A and B disc nodes (same as above) and C as a ram node.

> 2. With the same node arrangement listed above.... I set up A(created vhost,
> users, set permissions etc) and then clustered B against A,B (rabbitmqctl
> cluster nodeA nodeB). I took down A and my messages did not persist even
> though B should be a disk node. Is there something wrong with my steps?

Queues exist physically only on the node on which they were declared.
Clustering just makes them (and exchanges) accesible transparently on
all of the nodes.

Thus, if the queue was declared on A, and A was taken down, the messages
stored on the queue would become inaccesible.

If you want to never lose messages, have a look at our high-availability
clustering guide in the documentation section of the website.

> 3. What is the conventional/non-conventional way to determine whether or not
> individual nodes in a cluster are a disk or ram nodes?

To find out whether nodes are disc or ram, run
% rabbitmqctl status
on any node in the cluster.

Unfortunately, due to a bug, that command will not report the correct
node type, so it's not of much help to you now.  This problem has been
fixed in our default branch and will be in the release.

Cheers,
Alex