[rabbitmq-discuss] Q replication anxiety

[Tony Garnock-Jones]

Hi Ben,

You're quite right. While exchanges are stateless and (thus) distributed
across the cluster, queues are stateful and currently implemented in a
non-distributed way. The node to which a client is connected when it
issues a queue.declare that creates a new queue is the node that the
created queue is situated on until it's deleted and recreated.

So long as the disk that the persister log is on (i.e. where the mnesia
data files go) survives, your data will survive.

One potential alternative approach is to create duplicate queues on
separate nodes and consume from both, eliminating duplicates in the
receiving application. That way, if only one queue goes down, the other
keeps routing messages to the consuming application until the broken
system is repaired or replaced.

Regards,
  Tony


Ben Hyde wrote:
> This is causing me anxiety:  "... All data/state required for the  
> operation of a RabbitMQ broker is replicated across all nodes ...  
> exception to this are message queues, which currently only reside on  
> the node that created them ..."[1]
> 
> My setup is on ec2.   My testing randomly kill's machines; in service  
> of assuring the system can self heal.  Obviously I'm going to be  
> miserable if I kill the machines with Q's on them?  I guess i need to  
> be sure the disks the Q's fall onto aren't wiped (which they are today).
> 
> Is my anxiety misplaced, if not then how do others address it.
> 
>   - ben
> 
> [1] http://www.rabbitmq.com/clustering.html
> 
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


-- 
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ | Email: tonyg at lshift.net