[rabbitmq-discuss] Durable queues and high availability (broker failage)
Ben Hood
0x6e6562 at gmail.com
Wed Jul 15 23:54:57 BST 2009
Daniel,
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
nagios.
HTH,
Ben
More information about the rabbitmq-discuss
mailing list