[rabbitmq-discuss] Is the "master" node mandatory ?

Wed Oct 20 08:19:30 BST 2010

  Thank you for this long reply, I was not aware about that.

In our use case, all queues are not persistent. Thus, when a node 
fails, all messages of all queues it handles are lost (since 
messages are not replicated between nodes).
This situation is ok for us (anyway there is nothing we can do to 
prevent this, except to upgrade to RabbitMQ 2.0 with persistent 
queues, something we plan to do, but throughput being our main 
concern, we need to benchmark it first).

For the moment, what we must ensure is not to lose the global list 
of exchanges declared by producers on node failure.
AFAIK, this list is maintained in mnesia. If all nodes fails, 
because they are all RAM nodes, we lose this exchange list. But in 
that case, producers would recreate all exchange at reconnection 
time, whatever the node that is restarted first.

To summarize, the list of exchanges and queues are recreated at 
reconnection time by producers and consumers, thus, the "state" of 
the cluster can be lost. That's why I think we can use RAM node 
only. But maybe the "state" of the cluster is not limited to the 
list of exchanges and queues ?

Le 19/10/10 18:35, Matthew Sackman a écrit :
> On Tue, Oct 19, 2010 at 06:28:47PM +0200, Vincent Barat wrote:
>> My two nodes are RAM nodes actually.
> Ahh. From http://rabbitmq.com/clustering.html:
>
> "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."
>
> I think we used to prevent you from building RAM-node-only clusters. We
> must have changed behaviour there a while ago. It makes sense that the
> last node to die needs to be brought up first: if a node goes down and
> it knew that it was part of a cluster, then when coming back up, it'll
> remember it was part of a cluster and try to reconnect to it - it will
> be very aware that any data it holds (in this case, none!) will likely
> be out of date and it needs to resync from the other nodes in the
> cluster - it'll have no knowledge that the other nodes also went down.
>
> That said, it's been a while since I played around with clusters so my
> information might be out of date.
>
> Matthew
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>