[rabbitmq-discuss] high availability solutions?

[Rob Harrop]

E R wrote:
> Hello,
>
> I am wondering generally how one architects a rabbitmq system so that
> it is tolerant of a node going down or being taken offline.
>
> Specifically...
>
> 1. Is there ever a need to stop and restart the rabbitmq process, i.e.
> for maintenance, re-configuration, etc.?

The only real need to stop a rabbit node is for upgrade or to tweak some 
configuration settings.

>
> 2. If there is a need to restart the rabbitmq process, how do people
> generally assure that the queuing system is available when a rabbitmq
> server is down? Put retry code in the client? Have multiple servers
> that the client automatically fails over to?

You can run a cluster of servers each of which has a copy of the routing 
network set up by your client code.

You can kill one of these nodes, and with retry code in your client, 
have the client failover on to another node in the cluster.

However, in the current version of Rabbit, queue contents are *not* 
clustered - queues reside on a single node. So if you kill a node with a 
queue on it then you will lose any non-persistent messages from that queue.

This is currently being addressed and indeed, we are close to releasing 
our full Active/Active HA queues.

>
> 3. As a solution to the above problem, what about running a "buffering
> queue" in front of a main queue server? This would allow the main
> server to be taken offline for short periods of time while still
> allowing the application to continue inject messages into the queuing
> system. Good idea? overkill? introduces other problems?

This is certainly not a bad choice, and works quite well with the above 
situation. You simply have a process (which you could run using the 
shovel) that moves messages from your buffer to your backend queues.

At maintenance time, you disable this shovel process, wait for your 
backend queues to be empty and take the backend instances down.

>
> In my particular case latency in the queuing system is not a concern,
> but I don't want to hold up the application if a queuing node goes
> down or is taken offline.
>
> Thanks,
> ER
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss