[rabbitmq-discuss] Problem with Clustering

David Sinclair dsinclair at chariotsolutions.com
Fri Jan 8 14:31:31 GMT 2010

-- Sorry if you are getting this twice Matthew, it got bounced from the list


These are roughly the requirements for messaging

- need to ensure there are no messages dropped even if a node in the cluster
goes down (HA)
- easily scales
- zero configuration for brokers (nice to have, but Rabbit is pretty easy to
- seamless fail over for clients when the node they are connected to fails
(again, nice to have)

Along with those go the *regular* messaging requirements, point to point,
pub/sub, performance, security, integrates well, etc.

As far as the hardware/infrastructure being used for for HA, i was targeting
it for cloud deployment.

thanks again!

On Thu, Jan 7, 2010 at 4:17 PM, Stephen Day <sjaday at gmail.com> wrote:

> Matthew:
> This is the best description of the intent of RabbitMQ clustering I have
> heard yet. Specifically, the distinction that RabbitMQ clustering is for
> high volume messaging, rather than HA concerns. Do you mind adding some of
> these points to the RabbitMQ clustering guide (
> http://www.rabbitmq.com/clustering.html)?
> Steve
> On Thu, Jan 7, 2010 at 2:38 AM, Matthew Sackman <matthew at lshift.net>wrote:
>> Hi David,
>> You're using the latest default code, yes?
>> We've just changed the behaviour in this case - previously, yes, the
>> queue would be recreated. This is incorrect because it then causes many
>> problems when the failed node comes back up - you end up with the same
>> queue on both nodes with different concepts of what should be in the
>> queue. Exciting if undesireable things happen in this case.
>> Thus if a queue is declared but it's found that the queue does already
>> exist but is on a downed node, we return a 404, because it's really
>> saying "the node on which this queue exists can't be found".
>> From your code, I see you're declaring the queue durable. This really
>> reenforces the issue because if its durable, then persistent messages
>> shouldn't be lost, and yet if you want to be able to recreate the queue
>> on the other node, then it'll start empty, at which point, logically,
>> the contents of the queue have been lost.
>> In general, clustering should not be used for HA purposes. If you wish
>> to achive HA, then active/passive HA can be achieved by using shared
>> disk storage, heartbeat/pacemaker, maybe a tcp load balancer on the
>> front, and make sure you set the node names to localhost, and point both
>> rabbit instances at the same mnesia dir on the shared storage. When the
>> passive node comes up, it will recover everything from the storage.
>> Matthew
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100108/487c784e/attachment.htm 

More information about the rabbitmq-discuss mailing list