[rabbitmq-discuss] Durable queues and high availability (broker failage)

Ben Hood 0x6e6562 at gmail.com
Wed Jul 15 23:54:57 BST 2009


On Mon, Jun 29, 2009 at 10:12 AM, Daniel Lundin<dln at eintr.org> wrote:
> Q1) Is there some notification mechanism to rely on to reliably tell a
> queues has failed so apps can take measures to manage the failure, i.e
> recreate the queue or set up a "temporary fail" queue?

Not really.

> Q2) Is there a way to "replay" recovered messages from the failed,
> no-longer-relevant queue, into the newly/upon-failure created one? This
> seems it would allow graceful recovery, even automatically so, once the
> failed node does come back up.

Yes, persistent messages will be re-queued when a node is rehydrated.
This is a manual process though.

> So, what is the preferred way to handle node failure in a real-life
> rabbitmq-based app today?

I should think most people currently use a replicated FS to back
persistent messages with and monitor each node with something like



More information about the rabbitmq-discuss mailing list