[rabbitmq-discuss] clustering question
alexis.richardson at gmail.com
Thu Apr 1 01:02:42 BST 2010
On Wed, Mar 31, 2010 at 5:00 PM, Ian Ragsdale <ian.ragsdale at gmail.com> wrote:
> Hi Alexis, that's very useful information - using redis to dedupe messages between redundant servers is interesting.
Thanks - I agree.
> Regarding queues being unavailable when their nodes are down, what kind of behavior should I expect at the producer? If I publish a message to an exchange that is bound to a queue that is unavailable, should I receive an error, would the message be in limbo until the node came back up, or would it just not get pushed into the queue?
Not necessarily, since your message may reach another queue on another
node. If you publish with (say) key "bob" and two queues on two nodes
are bound with that key, then they both get a copy. That's pubsub in
the multicast style for you. For precise error reporting, I shall
defer to someone with more knowledge than I ...
> On Mar 31, 2010, at 6:44 PM, Alexis Richardson wrote:
>> Some background on this is here: http://www.rabbitmq.com/faq.html#performance
>> The unavailability of a node prevents any queues on that node from
>> receiving messages - instead they must find another path through the
>> broker. By the same token, client cannot consume from a queue whose
>> node is down. Queues cannot yet have an existence 'across' nodes. It
>> is however possible to set up 'back up' queues using normal AMQP. I
>> recommend @ezmobius presentation on Redis, found on slideshare, as
>> well as some of our video presentations on high availability - which
>> you can find via this link repo:
>> Does this help? Let us know.
>> On Wed, Mar 31, 2010 at 2:29 PM, Ian Ragsdale <ian.ragsdale at gmail.com> wrote:
>>> Hello all. I just set up a rabbitmq cluster using the clustering setup guide on the website, and I can report that the guide was easy to follow and worked well. However, I did have a question about a couple of statements made in the guide that I would like to clarify.
>>> The guide says:
>>> "RabbitMQ brokers tolerate the failure of individual nodes. Nodes can be started and stopped at will."
>>> As well as:
>>> "All data/state required for the operation of a RabbitMQ broker is replicated across all nodes, for reliability and scaling, with full ACID properties. An exception to this are message queues, which currently only reside on the node that created them, though they are visible and reachable from all nodes."
>>> So, from this I can assume that if one of my nodes go down the cluster will continue to operate, but how will that affect any queues that resided on the inoperative node? If I publish a message that was meant for one of those queues will it fail? Will clients that are subscribed to those queues continue to receive new messages? I'd just like to understand what the behavior will be so that I can plan accordingly.
>>> rabbitmq-discuss mailing list
>>> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss