[rabbitmq-discuss] Disk node vs ram node

[Vince Chang]

Thanks for your answers!

#2. I mean that if I send a message that is meant for Q1, where Q1 was originally on node A but now is down because node A is down, will the queue be created on the other nodes B,C? It looks like your answer is no, just to confirm? I am using the 1.7.2 Java client. Is there a way to set up the cluster such that a queue (like Q1 in our case) will be created(automatically) on other nodes (such as node B and node C) if node A goes down? What happens when I make either (node B or node C) or both (node B and node C) disk nodes? 

#3. Not sure if I should do anything before hand, but I ran the command you provided and got this output:
$ erl -sname mgmtsh -remsh rabbit at localhost
Erlang R13B03 (erts-5.7.4) [source] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]

*** ERROR: Shell process terminated! (^G to start new job) ***
{error_logger,{{2010,8,5},{14,52,59}},"~s~n",["Error in process <0.33.0> on node 'mgmtsh at ebony' with exit value: {badarg,[{erlang,list_to_existing_atom,[\"rabbit at ubuntu\"]},{dist_util,recv_challenge,1},{dist_util,handshake_we_started,1}]}\n"]}

=ERROR REPORT==== 5-Aug-2010::14:52:59 ===
Error in process <0.33.0> on node 'mgmtsh at ebony' with exit value: {badarg,[{erlang,list_to_existing_atom,["rabbit at ubuntu"]},{dist_util,recv_challenge,1},{dist_util,handshake_we_started,1}]}

FYI: I'm running Ubuntu and installed rabbitMQ 1.7.2 with sudo apt-get install rabbitmq-server. 

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

On Thu, Aug 05, 2010 at 01:49:51PM -0700, Vince Chang wrote:
> 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

I've just tried that on default.

All the nodes start up as disc nodes.  At that point, you turn *Node2*
into a ram node.  In the third group of commands, you also turn *Node3*
into a ram node.

So, the sequence is:
1. Start Node1 as a disc node
2. Cluster Node2 with Node1; Node2 becomes a ram node
3. Cluster Node3 with Node1; Node3 becomes a ram node
At the end, Node1 is disc; Node2 and Node3 are ram

> 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?

I'm not quite sure what you mean by ``message that creates the queue''.

If you declare a queue Q1 on node A with queue.declare, then Q1 will
reside on node A.  If node A goes down, all the messages on its queues
(including Q1) will become inaccessible.  If Q1 was declared as durable,
then the messages published as persistent on it will become available
when node A comes back online.

In a cluster, when a node goes down, its queues become inaccesbile.
They are *not* automatically created on other nodes.

Incidentally, which client are you using?

> 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? 

There's no way to do it with the provided tools.

If you're not squeamish about running a bit of Erlang, you could do
this:

% erl -sname mgmtsh -remsh rabbit at localhost

This gives you a remote Erlang shell named mgmtsh, connected to
rabbit at localhost

Then, running this should give you the disc nodes:
(rabbit at localhost)1> mnesia:table_info(rabbit_durable_exchange, disc_copies).

And running this should give you the ram nodes:
(rabbit at localhost)2> mnesia:table_info(rabbit_durable_exchange, ram_copies).


Cheers,
Alex