[rabbitmq-discuss] upgrading a cluster

Simon MacMullen simon at rabbitmq.com
Wed Aug 22 14:53:14 BST 2012

On 22/08/12 13:44, Aaron Westendorf wrote:
> To date we've accepted the downtime associated with upgrading our
> rabbit cluster as we perform that work infrequently. In evaluating our
> planned improvements for the coming year, decreasing downtime is an
> important goal.
> With that in mind I reviewed the documentation for upgrades and found
> that it is still recommended/required that the whole cluster be shut
> down for an upgrade. That doesn't fit with our goals, so my questions
> are:
> * is that recommendation up to date?


> * is it a requirement or recommendation?

Pretty much a requirement I'm afraid. And we're intending to enforce it 
more strictly in future, since we see reports of people running 
mixed-version clusters and getting weird errors.

> * is there a configuration that would give us the benefit of
> clustering and mirrored queues without this requirement?

If you want mirrored queues you need clustering. But you don't need to 
have only *one* cluster.

You could have two separate clusters (they could both run on the same 
set of machines of course) - and either keep them completely separate 
with your clients connecting to both, or have the two clusters connected 
together with the shovel or federation.

You can then take one cluster at a time offline to upgrade it.

> Our use of Rabbit is fairly simple. We have a front-end web server to
> handle client requests, queue messages to Rabbit, and run a pool of
> consumers to handle the requests. We haven't yet evaluated other MQ
> options as we've been mostly happy with Rabbit for the past 3 years,
> but this required downtime is a sticking point.

I hope the above seems like a feasible option.

It's unlikely we'll support mixed-version clusters any time soon - the 
nodes of a cluster are quite tightly integrated, and there are a *lot* 
of points where they interact - the work involved in make sure internal 
messages get correctly translated at each point and in testing the whole 
thing works would be quite alarming (and it would be a cost on every 
future release, not just a one-off).

I hope this helps.

Cheers, Simon

Simon MacMullen
RabbitMQ, VMware

More information about the rabbitmq-discuss mailing list