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

Mon Nov 1 13:10:45 GMT 2010

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

The "state" of the cluster is just the names of the nodes currently in
the cluster and the queues/exchanges declared on said nodes.

All nodes, whether ram or disc record the names of the other nodes in
the cluster, so even ram nodes will rejoin the cluster when restarted.

Ram nodes don't store most of their mnesia tables on disk, so they won't
remember queues/exchanges/messages on restart.

Your scenario seems fine: if you don't mind having to redeclare
queues/exchanges on every use and losing messages on node failure, using
a cluster of all ram nodes is ok.

Also, sorry for the late reply.

Cheers,
Alex

On Wed, Oct 20, 2010 at 09:19:30AM +0200, Vincent Barat wrote:
>   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
> >
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss