[rabbitmq-discuss] Problem with Clustering
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.
On Thu, Jan 7, 2010 at 4:17 PM, Stephen Day <sjaday at gmail.com> wrote:
> 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 (
> 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.
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss