[rabbitmq-discuss] Round-robin queue failover
Jason J. W. Williams
jasonjwwilliams at gmail.com
Mon Oct 26 17:10:17 GMT 2009
The solution we use is pretty much what Alexis describes. No
clustering. And both consumers and producers declare queues on a fail
over to a hot standby/passive server. That way messages are never
lost. When the old server comes back up we fail back.
Sent via iPhone
On Oct 26, 2009, at 10:23, Alexis Richardson <alexis.richardson at gmail.com
> On Mon, Oct 26, 2009 at 4:04 PM, Sebastian <mail at sebastian-latza.de>
>> Kyle Schaffrick:
>>> Attempting to create two identically-named queues will
>>> result in declaring the same queue twice; the two consumers then
>>> consuming from that queue will see load-balancing behavior.
>> Thanks for the clarification. Since this does not work: how do I
>> achieve reliable persistent message delivery even if the one node
>> holding the queue dies?
> At the risk of being seen as pedantic...
> You could achieve it by waiting for the node to recover from disk. In
> other words: RabbitMQ provides "eventual delivery" out of the box. If
> you want to 'persist more reliably' than on one drive using RabbitMQ
> out of the box, then use a RAID or a SAN.
> I am guessing that what you mean is *availability* in which a message
> can always reach a suitable queue even if the sending client loses its
> connection with the node that crashed. The problem with using a
> single node is the time it takes to recover, and client reconnection
> costs (if any). The time to recover is partly influenced by how much
> state has to recover, and partly by the size of the unavailability
> window that you can tolerate.
> Many applications don't like to wait more than (say) 1ms, 10ms or 50ms
> before they can send their message. In this case you will typically
> want to send a message *before* the crashed node has been able to
> recover. You can achieve this in two ways:
> 1. You don't care about replicating state and can use any other queue
> as a 'suitable queue'. This is easy - just make sure the right
> consumers and routes are wired up.
> 2. You do care about replicating state - which I think is the case you
> have in mind. Then you can fail over to a passive server. We can
> provide some more info on this if you like -- we have done it for a
> few people but it is not yet 'available OOTB'. (You can also do
> active/active but it is much more fiddly atm).
>> As stated before my take would be to replicate
>> queues client-side on independent brokers, but this seems to be
>> getting quite complicated as the queues have to be "double-declared",
>> linked and properly re-initialized on startup of a new empty broker
>> (basically doing some kind of client-side clustering).
> Right. I think you probably want case 2 above.
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss